Return to gcc.info-6 CVS log

Up to [Apple XNU] / GNUtools / cc

Annotation of GNUtools/cc/gcc.info-6, revision 1.1

1.1     ! root        1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
        !             2: file gcc.texi.
        !             3: 
        !             4:    This file documents the use and the internals of the GNU compiler.
        !             5: 
        !             6:    Published by the Free Software Foundation 675 Massachusetts Avenue
        !             7: Cambridge, MA 02139 USA
        !             8: 
        !             9:    Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
        !            10: 
        !            11:    Permission is granted to make and distribute verbatim copies of this
        !            12: manual provided the copyright notice and this permission notice are
        !            13: preserved on all copies.
        !            14: 
        !            15:    Permission is granted to copy and distribute modified versions of
        !            16: this manual under the conditions for verbatim copying, provided also
        !            17: that the sections entitled "GNU General Public License" and "Protect
        !            18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
        !            19: original, and provided that the entire resulting derived work is
        !            20: distributed under the terms of a permission notice identical to this
        !            21: one.
        !            22: 
        !            23:    Permission is granted to copy and distribute translations of this
        !            24: manual into another language, under the above conditions for modified
        !            25: versions, except that the sections entitled "GNU General Public
        !            26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
        !            27: permission notice, may be included in translations approved by the Free
        !            28: Software Foundation instead of in the original English.
        !            29: 
        !            30: 
        !            31: File: gcc.info,  Node: PA Install,  Next: Sun Install,  Prev: Cross-Compiler,  Up: Installation
        !            32: 
        !            33: Installing on the HP Precision Architecture
        !            34: ===========================================
        !            35: 
        !            36:    There are two variants of this CPU, called 1.0 and 1.1, which have
        !            37: different machine descriptions.  You must use the right one for your
        !            38: machine.  All 7NN machines and 8N7 machines use 1.1, while all other
        !            39: 8NN machines use 1.0.
        !            40: 
        !            41:    The easiest way to handle this problem is to use `configure hpNNN'
        !            42: or `configure hpNNN-hpux', where NNN is the model number of the
        !            43: machine.  Then `configure' will figure out if the machine is a 1.0 or
        !            44: 1.1.  Use `uname -a' to find out the model number of your machine.
        !            45: 
        !            46:    `-g' does not work on HP-UX, since that system uses a peculiar
        !            47: debugging format which GNU CC does not know about.  There are
        !            48: preliminary versions of GAS and GDB for the HP-PA which do work with
        !            49: GNU CC for debugging.  You can get them by anonymous ftp from
        !            50: `jaguar.cs.utah.edu' `dist' subdirectory.  You would need to install
        !            51: GAS in the file
        !            52: 
        !            53:      /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as
        !            54: 
        !            55: where CONFIGURATION is the configuration name (perhaps `hpNNN-hpux')
        !            56: and GCCVERSION is the GNU CC version number.  Do this *before* starting
        !            57: the build process, otherwise you will get errors from the HPUX
        !            58: assembler while building `libgcc2.a'.  The command
        !            59: 
        !            60:      make install-dir
        !            61: 
        !            62: will create the necessary directory hierarchy so you can install GAS
        !            63: before building GCC.
        !            64: 
        !            65:    If you obtained GAS before October 6, 1992 it is highly recommended
        !            66: you get a new one to avoid several bugs which have been discovered
        !            67: recently.
        !            68: 
        !            69:    To enable debugging, configure GNU CC with the `--gas' option before
        !            70: building.
        !            71: 
        !            72:    It has been reported that GNU CC produces invalid assembly code for
        !            73: 1.1 machines running HP-UX 8.02 when using the HP assembler.  Typically
        !            74: the errors look like this:
        !            75:      as: bug.s @line#15 [err#1060]
        !            76:        Argument 0 or 2 in FARG upper
        !            77:               - lookahead = ARGW1=FR,RTNVAL=GR
        !            78:      as: foo.s @line#28 [err#1060]
        !            79:        Argument 0 or 2 in FARG upper
        !            80:               - lookahead = ARGW1=FR
        !            81: 
        !            82:    You can check the version of HP-UX you are running by executing the
        !            83: command `uname -r'.   If you are indeed running HP-UX 8.02 on a 1.1
        !            84: machine and using the HP assembler then configure GCC with
        !            85: "hp700-hpux8.02".
        !            86: 
        !            87: 
        !            88: File: gcc.info,  Node: Sun Install,  Next: 3b1 Install,  Prev: PA Install,  Up: Installation
        !            89: 
        !            90: Installing GNU CC on the Sun
        !            91: ============================
        !            92: 
        !            93:    On Solaris (version 2.1), do not use the linker or other tools in
        !            94: `/usr/ucb' to build GNU CC.  Use `/usr/ccs/bin'.
        !            95: 
        !            96:    Make sure the environment variable `FLOAT_OPTION' is not set when
        !            97: you compile `libgcc.a'.  If this option were set to `f68881' when
        !            98: `libgcc.a' is compiled, the resulting code would demand to be linked
        !            99: with a special startup file and would not link properly without special
        !           100: pains.
        !           101: 
        !           102:    The GNU compiler does not really support the Super SPARC processor
        !           103: that is used in SPARC Station 10 and similar class machines.  You can
        !           104: get code that runs by specifying `sparc' as the cpu type; however, its
        !           105: performance is not very good, and may vary widely according to the
        !           106: compiler version and optimization options used.  This is because the
        !           107: instruction scheduling parameters designed for the Sparc are not correct
        !           108: for the Super SPARC.  Implementing scheduling parameters for the Super
        !           109: SPARC might be a good project for someone who is willing to learn a
        !           110: great deal about instruction scheduling in GNU CC.
        !           111: 
        !           112:    There is a bug in `alloca' in certain versions of the Sun library.
        !           113: To avoid this bug, install the binaries of GNU CC that were compiled by
        !           114: GNU CC.  They use `alloca' as a built-in function and never the one in
        !           115: the library.
        !           116: 
        !           117:    Some versions of the Sun compiler crash when compiling GNU CC.  The
        !           118: problem is a segmentation fault in cpp.  This problem seems to be due to
        !           119: the bulk of data in the environment variables.  You may be able to avoid
        !           120: it by using the following command to compile GNU CC with Sun CC:
        !           121: 
        !           122:      make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
        !           123: 
        !           124: 
        !           125: File: gcc.info,  Node: 3b1 Install,  Next: Unos Install,  Prev: Sun Install,  Up: Installation
        !           126: 
        !           127: Installing GNU CC on the 3b1
        !           128: ============================
        !           129: 
        !           130:    Installing GNU CC on the 3b1 is difficult if you do not already have
        !           131: GNU CC running, due to bugs in the installed C compiler.  However, the
        !           132: following procedure might work.  We are unable to test it.
        !           133: 
        !           134:   1. Comment out the `#include "config.h"' line on line 37 of `cccp.c'
        !           135:      and do `make cpp'.  This makes a preliminary version of GNU cpp.
        !           136: 
        !           137:   2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
        !           138:      file name.
        !           139: 
        !           140:   3. Undo your change in `cccp.c', or reinstall the original version,
        !           141:      and do `make cpp' again.
        !           142: 
        !           143:   4. Copy this final version of GNU cpp into `/lib/cpp'.
        !           144: 
        !           145:   5. Replace every occurrence of `obstack_free' in the file `tree.c'
        !           146:      with `_obstack_free'.
        !           147: 
        !           148:   6. Run `make' to get the first-stage GNU CC.
        !           149: 
        !           150:   7. Reinstall the original version of `/lib/cpp'.
        !           151: 
        !           152:   8. Now you can compile GNU CC with itself and install it in the normal
        !           153:      fashion.
        !           154: 
        !           155: 
        !           156: File: gcc.info,  Node: Unos Install,  Next: VMS Install,  Prev: 3b1 Install,  Up: Installation
        !           157: 
        !           158: Installing GNU CC on Unos
        !           159: =========================
        !           160: 
        !           161:    Use `configure unos' for building on Unos.
        !           162: 
        !           163:    The Unos assembler is named `casm' instead of `as'.  For some
        !           164: strange reason linking `/bin/as' to `/bin/casm' changes the behavior,
        !           165: and does not work.  So, when installing GNU CC, you should install the
        !           166: following script as `as' in the subdirectory where the passes of GCC
        !           167: are installed:
        !           168: 
        !           169:      #!/bin/sh
        !           170:      casm $*
        !           171: 
        !           172:    The default Unos library is named `libunos.a' instead of `libc.a'.
        !           173: To allow GNU CC to function, either change all references to `-lc' in
        !           174: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'.
        !           175: 
        !           176:    When compiling GNU CC with the standard compiler, to overcome bugs in
        !           177: the support of `alloca', do not use `-O' when making stage 2.  Then use
        !           178: the stage 2 compiler with `-O' to make the stage 3 compiler.  This
        !           179: compiler will have the same characteristics as the usual stage 2
        !           180: compiler on other systems.  Use it to make a stage 4 compiler and
        !           181: compare that with stage 3 to verify proper compilation.
        !           182: 
        !           183:    (Perhaps simply defining `ALLOCA' in `x-crds' as described in the
        !           184: comments there will make the above paragraph superfluous.  Please
        !           185: inform us of whether this works.)
        !           186: 
        !           187:    Unos uses memory segmentation instead of demand paging, so you will
        !           188: need a lot of memory.  5 Mb is barely enough if no other tasks are
        !           189: running.  If linking `cc1' fails, try putting the object files into a
        !           190: library and linking from that library.
        !           191: 
        !           192: 
        !           193: File: gcc.info,  Node: VMS Install,  Next: WE32K Install,  Prev: Unos Install,  Up: Installation
        !           194: 
        !           195: Installing GNU CC on VMS
        !           196: ========================
        !           197: 
        !           198:    The VMS version of GNU CC is distributed in a backup saveset
        !           199: containing both source code and precompiled binaries.
        !           200: 
        !           201:    To install the `gcc' command so you can use the compiler easily, in
        !           202: the same manner as you use the VMS C compiler, you must install the VMS
        !           203: CLD file for GNU CC as follows:
        !           204: 
        !           205:   1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
        !           206:      point to the directories where the GNU CC executables
        !           207:      (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are
        !           208:      kept respectively.  This should be done with the commands:
        !           209: 
        !           210:           $ assign /system /translation=concealed -
        !           211:             disk:[gcc.] gnu_cc
        !           212:           $ assign /system /translation=concealed -
        !           213:             disk:[gcc.include.] gnu_cc_include
        !           214: 
        !           215:      with the appropriate disk and directory names.  These commands can
        !           216:      be placed in your system startup file so they will be executed
        !           217:      whenever the machine is rebooted.  You may, if you choose, do this
        !           218:      via the `GCC_INSTALL.COM' script in the `[GCC]' directory.
        !           219: 
        !           220:   2. Install the `GCC' command with the command line:
        !           221: 
        !           222:           $ set command /table=sys$common:[syslib]dcltables -
        !           223:             /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc
        !           224:           $ install replace sys$common:[syslib]dcltables
        !           225: 
        !           226:   3. To install the help file, do the following:
        !           227: 
        !           228:           $ library/help sys$library:helplib.hlb gcc.hlp
        !           229: 
        !           230:      Now you can invoke the compiler with a command like `gcc /verbose
        !           231:      file.c', which is equivalent to the command `gcc -v -c file.c' in
        !           232:      Unix.
        !           233: 
        !           234:    If you wish to use GNU C++ you must first install GNU CC, and then
        !           235: perform the following steps:
        !           236: 
        !           237:   1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the
        !           238:      directory where the preprocessor will search for the C++ header
        !           239:      files.  This can be done with the command:
        !           240: 
        !           241:           $ assign /system /translation=concealed -
        !           242:             disk:[gcc.gxx_include.] gnu_gxx_include
        !           243: 
        !           244:      with the appropriate disk and directory name.  If you are going to
        !           245:      be using libg++, this is where the libg++ install procedure will
        !           246:      install the libg++ header files.
        !           247: 
        !           248:   2. Obtain the file `gcc-cc1plus.exe', and place this in the same
        !           249:      directory that `gcc-cc1.exe' is kept.
        !           250: 
        !           251:      The GNU C++ compiler can be invoked with a command like `gcc /plus
        !           252:      /verbose file.cc', which is equivalent to the command `g++ -v -c
        !           253:      file.cc' in Unix.
        !           254: 
        !           255:    We try to put corresponding binaries and sources on the VMS
        !           256: distribution tape.  But sometimes the binaries will be from an older
        !           257: version than the sources, because we don't always have time to update
        !           258: them.  (Use the `/version' option to determine the version number of
        !           259: the binaries and compare it with the source file `version.c' to tell
        !           260: whether this is so.)  In this case, you should use the binaries you get
        !           261: to recompile the sources.  If you must recompile, here is how:
        !           262: 
        !           263:   1. Execute the command procedure `vmsconfig.com' to set up the files
        !           264:      `tm.h', `config.h', `aux-output.c', and `md.', and to create files
        !           265:      `tconfig.h' and `hconfig.h'.  This procedure also creates several
        !           266:      linker option files used by `make-cc1.com' and a data file used by
        !           267:      `make-l2.com'.
        !           268: 
        !           269:           $ @vmsconfig.com
        !           270: 
        !           271:   2. Setup the logical names and command tables as defined above.  In
        !           272:      addition, define the VMS logical name `GNU_BISON' to point at the
        !           273:      to the directories where the Bison executable is kept.  This
        !           274:      should be done with the command:
        !           275: 
        !           276:           $ assign /system /translation=concealed -
        !           277:             disk:[bison.] gnu_bison
        !           278: 
        !           279:      You may, if you choose, use the `INSTALL_BISON.COM' script in the
        !           280:      `[BISON]' directory.
        !           281: 
        !           282:   3. Install the `BISON' command with the command line:
        !           283: 
        !           284:           $ set command /table=sys$common:[syslib]dcltables -
        !           285:             /output=sys$common:[syslib]dcltables -
        !           286:             gnu_bison:[000000]bison
        !           287:           $ install replace sys$common:[syslib]dcltables
        !           288: 
        !           289:   4. Type `@make-gcc' to recompile everything (alternatively, submit
        !           290:      the file `make-gcc.com' to a batch queue).  If you wish to build
        !           291:      the GNU C++ compiler as well as the GNU CC compiler, you must
        !           292:      first edit `make-gcc.com' and follow the instructions that appear
        !           293:      in the comments.
        !           294: 
        !           295:   5. In order to use GCC, you need a library of functions which GCC
        !           296:      compiled code will call to perform certain tasks, and these
        !           297:      functions are defined in the file `libgcc2.c'.  To compile this
        !           298:      you should use the command procedure `make-l2.com', which will
        !           299:      generate the library `libgcc2.olb'.  `libgcc2.olb' should be built
        !           300:      using the compiler built from the same distribution that
        !           301:      `libgcc2.c' came from, and `make-gcc.com' will automatically do
        !           302:      all of this for you.
        !           303: 
        !           304:      To install the library, use the following commands:
        !           305: 
        !           306:           $ library gnu_cc:[000000]gcclib/delete=(new,eprintf)
        !           307:           $ library gnu_cc:[000000]gcclib/delete=L_*
        !           308:           $ library libgcc2/extract=*/output=libgcc2.obj
        !           309:           $ library gnu_cc:[000000]gcclib libgcc2.obj
        !           310: 
        !           311:      The first command simply removes old modules that will be replaced
        !           312:      with modules from `libgcc2' under different module names.  The
        !           313:      modules `new' and `eprintf' may not actually be present in your
        !           314:      `gcclib.olb'--if the VMS librarian complains about those modules
        !           315:      not being present, simply ignore the message and continue on with
        !           316:      the next command.  The second command removes the modules that
        !           317:      came from the previous version of the library `libgcc2.c'.
        !           318: 
        !           319:      Whenever you update the compiler on your system, you should also
        !           320:      update the library with the above procedure.
        !           321: 
        !           322:   6. You may wish to build GCC in such a way that no files are written
        !           323:      to the directory where the source files reside.  An example would
        !           324:      be the when the source files are on a read-only disk.  In these
        !           325:      cases, execute the following DCL commands (substituting your
        !           326:      actual path names):
        !           327: 
        !           328:           $ assign dua0:[gcc.build_dir.]/translation=concealed, -
        !           329:                    dua1:[gcc.source_dir.]/translation=concealed  gcc_build
        !           330:           $ set default gcc_build:[000000]
        !           331: 
        !           332:      where the directory `dua1:[gcc.source_dir]' contains the source
        !           333:      code, and the directory `dua0:[gcc.build_dir]' is meant to contain
        !           334:      all of the generated object files and executables.  Once you have
        !           335:      done this, you can proceed building GCC as described above.  (Keep
        !           336:      in mind that `gcc_build' is a rooted logical name, and thus the
        !           337:      device names in each element of the search list must be an actual
        !           338:      physical device name rather than another rooted logical name).
        !           339: 
        !           340:   7. *If you are building GNU CC with a previous version of GNU CC, you
        !           341:      also should check to see that you have the newest version of the
        !           342:      assembler*.  In particular, GNU CC version 2 treats global constant
        !           343:      variables slightly differently from GNU CC version 1, and GAS
        !           344:      version 1.38.1 does not have the patches required to work with GCC
        !           345:      version 2.  If you use GAS 1.38.1, then `extern const' variables
        !           346:      will not have the read-only bit set, and the linker will generate
        !           347:      warning messages about mismatched psect attributes for these
        !           348:      variables.  These warning messages are merely a nuisance, and can
        !           349:      safely be ignored.
        !           350: 
        !           351:      If you are compiling with a version of GNU CC older than 1.33,
        !           352:      specify `/DEFINE=("inline=")' as an option in all the
        !           353:      compilations.  This requires editing all the `gcc' commands in
        !           354:      `make-cc1.com'.  (The older versions had problems supporting
        !           355:      `inline'.)  Once you have a working 1.33 or newer GNU CC, you can
        !           356:      change this file back.
        !           357: 
        !           358:   8. If you want to build GNU CC with the VAX C compiler, you will need
        !           359:      to make minor changes in `make-cccp.com' and `make-cc1.com' to
        !           360:      choose alternate definitions of `CC', `CFLAGS', and `LIBS'.  See
        !           361:      comments in those files.  However, you must also have a working
        !           362:      version of the GNU assembler (GNU as, aka GAS) as it is used as
        !           363:      the back-end for GNU CC to produce binary object modules and is
        !           364:      not included in the GNU CC sources.  GAS is also needed to compile
        !           365:      `libgcc2' in order to build `gcclib' (see above); `make-l2.com'
        !           366:      expects to be able to find it operational in
        !           367:      `gnu_cc:[000000]gnu-as.exe'.
        !           368: 
        !           369:      To use GNU CC on VMS, you need the VMS driver programs `gcc.exe',
        !           370:      `gcc.com', and `gcc.cld'.  They are distributed with the VMS
        !           371:      binaries (`gcc-vms') rather than the GNU CC sources.  GAS is also
        !           372:      included in `gcc-vms', as is Bison.
        !           373: 
        !           374:      Once you have successfully built GNU CC with VAX C, you should use
        !           375:      the resulting compiler to rebuild itself.  Before doing this, be
        !           376:      sure to restore the `CC', `CFLAGS', and `LIBS' definitions in
        !           377:      `make-cccp.com' and `make-cc1.com'.  The second generation
        !           378:      compiler will be able to take advantage of many optimizations that
        !           379:      must be suppressed when building with other compilers.
        !           380: 
        !           381:    Under previous versions of GNU CC, the generated code would
        !           382: occasionally give strange results when linked with the sharable
        !           383: `VAXCRTL' library.  Now this should work.
        !           384: 
        !           385:    Even with this version, however, GNU CC itself should not be linked
        !           386: with the sharable `VAXCRTL'.  The version of `qsort' in `VAXCRTL' has a
        !           387: bug (known to be present in VMS versions V4.6 through V5.5) which
        !           388: causes the compiler to fail.
        !           389: 
        !           390:    The executables are generated by `make-cc1.com' and `make-cccp.com'
        !           391: use the object library version of `VAXCRTL' in order to make use of the
        !           392: `qsort' routine in `gcclib.olb'.  If you wish to link the compiler
        !           393: executables with the shareable image version of `VAXCRTL', you should
        !           394: edit the file `tm.h' (created by `vmsconfig.com') to define the macro
        !           395: `QSORT_WORKAROUND'.
        !           396: 
        !           397:    `QSORT_WORKAROUND' is always defined when GNU CC is compiled with
        !           398: VAX C, to avoid a problem in case `gcclib.olb' is not yet available.
        !           399: 
        !           400: 
        !           401: File: gcc.info,  Node: WE32K Install,  Next: MIPS Install,  Prev: VMS Install,  Up: Installation
        !           402: 
        !           403: Installing GNU CC on the WE32K
        !           404: ==============================
        !           405: 
        !           406:    These computers are also known as the 3b2, 3b5, 3b20 and other
        !           407: similar names.  (However, the 3b1 is actually a 68000; see *Note 3b1
        !           408: Install::.)
        !           409: 
        !           410:    Don't use `-g' when compiling with the system's compiler.  The
        !           411: system's linker seems to be unable to handle such a large program with
        !           412: debugging information.
        !           413: 
        !           414:    The system's compiler runs out of capacity when compiling `stmt.c'
        !           415: in GNU CC.  You can work around this by building `cpp' in GNU CC first,
        !           416: then use that instead of the system's preprocessor with the system's C
        !           417: compiler to compile `stmt.c'.  Here is how:
        !           418: 
        !           419:      mv /lib/cpp /lib/cpp.att
        !           420:      cp cpp /lib/cpp.gnu
        !           421:      echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp
        !           422:      chmod +x /lib/cpp
        !           423: 
        !           424:    The system's compiler produces bad code for some of the GNU CC
        !           425: optimization files.  So you must build the stage 2 compiler without
        !           426: optimization.  Then build a stage 3 compiler with optimization.  That
        !           427: executable should work.  Here are the necessary commands:
        !           428: 
        !           429:      make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g"
        !           430:      make stage2
        !           431:      make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"
        !           432: 
        !           433:    You may need to raise the ULIMIT setting to build a C++ compiler, as
        !           434: the file `cc1plus' is larger than one megabyte.
        !           435: 
        !           436: 
        !           437: File: gcc.info,  Node: MIPS Install,  Next: Collect2,  Prev: WE32K Install,  Up: Installation
        !           438: 
        !           439: Installing GNU CC on the MIPS
        !           440: =============================
        !           441: 
        !           442:    See *Note Installation:: about whether to use either of the options
        !           443: `--with-stabs' or `--with-gnu-as'.
        !           444: 
        !           445:    The MIPS C compiler needs to be told to increase its table size for
        !           446: switch statements with the `-Wf,-XNg1500' option in order to compile
        !           447: `cp-parse.c'.  If you use the `-O2' optimization option, you also need
        !           448: to use `-Olimit 3000'.  Both of these options are automatically
        !           449: generated in the `Makefile' that the shell script `configure' builds.
        !           450: If you override the `CC' make variable and use the MIPS compilers, you
        !           451: may need to add `-Wf,-XNg1500 -Olimit 3000'.
        !           452: 
        !           453:    MIPS computers running RISC-OS can support four different
        !           454: personalities: default, BSD 4.3, System V.3, and System V.4 (older
        !           455: versions of RISC-OS don't support V.4).  To configure GCC for these
        !           456: platforms use the following configurations:
        !           457: 
        !           458: `mips-mips-riscos`rev''
        !           459:      Default configuration for RISC-OS, revision `rev'.
        !           460: 
        !           461: `mips-mips-riscos`rev'bsd'
        !           462:      BSD 4.3 configuration for RISC-OS, revision `rev'.
        !           463: 
        !           464: `mips-mips-riscos`rev'sysv4'
        !           465:      System V.4 configuration for RISC-OS, revision `rev'.
        !           466: 
        !           467: `mips-mips-riscos`rev'sysv'
        !           468:      System V.3 configuration for RISC-OS, revision `rev'.
        !           469: 
        !           470:    The revision `rev' mentioned above is the revision of RISC-OS to
        !           471: use.  You must reconfigure GCC when going from a RISC-OS revision 4 to
        !           472: RISC-OS revision 5.  This has the effect of avoiding a linker bug (see
        !           473: *Note Installation Problems:: for more details).
        !           474: 
        !           475:    DECstations can support three different personalities: Ultrix, DEC
        !           476: OSF/1, and OSF/rose.  To configure GCC for these platforms use the
        !           477: following configurations:
        !           478: 
        !           479: `decstation-ultrix'
        !           480:      Ultrix configuration.
        !           481: 
        !           482: `decstation-osf1'
        !           483:      Dec's version of OSF/1.
        !           484: 
        !           485: `decstation-osfrose'
        !           486:      Open Software Foundation reference port of OSF/1 which uses the
        !           487:      OSF/rose object file format instead of ECOFF.  Normally, you would
        !           488:      not select this configuration.
        !           489: 
        !           490:    On Irix version 4.0.5F, and perhaps on some other versions as well,
        !           491: there is an assembler bug that reorders instructions incorrectly.  To
        !           492: work around it, specify the target configuration `mips-sgi-irix4loser'.
        !           493: This configuration inhibits assembler optimization.
        !           494: 
        !           495:    You can turn off assembler optimization in a compiler configured with
        !           496: target `mips-sgi-irix4' using the `-noasmopt' option.  This compiler
        !           497: option passes the option `-O0' to the assembler, to inhibit reordering.
        !           498: 
        !           499:    The `-noasmopt' option can be useful for testing whether a problem
        !           500: is due to erroneous assembler reordering.  Even if a problem does not go
        !           501: away with `-noasmopt', it may still be due to assembler
        !           502: reordering--perhaps GNU CC itself was miscompiled as a result.
        !           503: 
        !           504:    We know this is inconvenient, but it's the best that can be done at
        !           505: the last minute.
        !           506: 
        !           507: 
        !           508: File: gcc.info,  Node: Collect2,  Next: Header Dirs,  Prev: MIPS Install,  Up: Installation
        !           509: 
        !           510: `collect2'
        !           511: ==========
        !           512: 
        !           513:    Many target systems do not have support in the assembler and linker
        !           514: for "constructors"--initialization functions to be called before the
        !           515: official "start" of `main'.  On such systems, GNU CC uses a utility
        !           516: called `collect2' to arrange to call these functions at start time.
        !           517: 
        !           518:    The program `collect2' works by linking the program once and looking
        !           519: through the linker output file for symbols with particular names
        !           520: indicating they are constructor functions.  If it finds any, it creates
        !           521: a new temporary `.c' file containing a table of them, compiles it, and
        !           522: links the program a second time including that file.
        !           523: 
        !           524:    The actual calls to the constructors are carried out by a subroutine
        !           525: called `__main', which is called (automatically) at the beginning of
        !           526: the body of `main' (provided `main' was compiled with GNU CC).
        !           527: 
        !           528:    The program `collect2' is installed as `ld' in the directory where
        !           529: the passes of the compiler are installed.  When `collect2' needs to
        !           530: find the *real* `ld', it tries the following file names:
        !           531: 
        !           532:    * `gld' in the directories listed in the compiler's search
        !           533:      directories.
        !           534: 
        !           535:    * `gld' in the directories listed in the environment variable `PATH'.
        !           536: 
        !           537:    * `real-ld' in the compiler's search directories.
        !           538: 
        !           539:    * `real-ld' in `PATH'.
        !           540: 
        !           541:    * `ld' in `PATH'.
        !           542: 
        !           543:    "The compiler's search directories" means all the directories where
        !           544: `gcc' searches for passes of the compiler.  This includes directories
        !           545: that you specify with `-B'.
        !           546: 
        !           547:    Cross-compilers search a little differently:
        !           548: 
        !           549:    * `gld' in the compiler's search directories.
        !           550: 
        !           551:    * `TARGET-gld' in `PATH'.
        !           552: 
        !           553:    * `real-ld' in the compiler's search directories.
        !           554: 
        !           555:    * `TARGET-real-ld' in `PATH'.
        !           556: 
        !           557:    * `TARGET-ld' in `PATH'.
        !           558: 
        !           559:    `collect2' does not search for `ld' using the compiler's search
        !           560: directories, because if it did, it would find itself--not the real
        !           561: `ld'--and this could lead to infinite recursion.  However, the
        !           562: directory where `collect2' is installed might happen to be in `PATH'.
        !           563: That could lead `collect2' to invoke itself anyway.  when looking for
        !           564: `ld'.
        !           565: 
        !           566:    To prevent this, `collect2' explicitly avoids running `ld' using the
        !           567: file name under which `collect2' itself was invoked.  In fact, it
        !           568: remembers up to two such names--in case one copy of `collect2' finds
        !           569: another copy (or version) of `collect2' installed as `ld' in a second
        !           570: place in the search path.
        !           571: 
        !           572:    If two file names to avoid are not sufficient, you may still
        !           573: encounter an infinite recursion of `collect2' processes.  When this
        !           574: happens.  check all the files installed as `ld' in any of the
        !           575: directories searched, and straighten out the situation.
        !           576: 
        !           577:    (In a future version, we will probably change `collect2' to avoid
        !           578: any reinvocation of a file from which any parent `collect2' was run.)
        !           579: 
        !           580: 
        !           581: File: gcc.info,  Node: Header Dirs,  Prev: Collect2,  Up: Installation
        !           582: 
        !           583: Standard Header File Directories
        !           584: ================================
        !           585: 
        !           586:    `GCC_INCLUDE_DIR' means the same thing for native and cross.  It is
        !           587: where GNU CC stores its private include files, and also where GNU CC
        !           588: stores the fixed include files.  A cross compiled GNU CC runs
        !           589: `fixincludes' on the header files in `$(tooldir)/include'.  (If the
        !           590: cross compilation header files need to be fixed, they must be installed
        !           591: before GNU CC is built.  If the cross compilation header files are
        !           592: already suitable for ANSI C and GNU CC, nothing special need be done).
        !           593: 
        !           594:    `GPLUS_INCLUDE_DIR' means the same thing for native and cross.  It
        !           595: is where `g++' looks first for header files.  `libg++' installs only
        !           596: target independent header files in that directory.
        !           597: 
        !           598:    `LOCAL_INCLUDE_DIR' is used only for a native compiler.  It is
        !           599: normally `/usr/local/include'.  GNU CC searches this directory so that
        !           600: users can install header files in `/usr/local/include'.
        !           601: 
        !           602:    `CROSS_INCLUDE_DIR' is used only for a cross compiler.  GNU CC
        !           603: doesn't install anything there.
        !           604: 
        !           605:    `TOOL_INCLUDE_DIR' is used for both native and cross compilers.  It
        !           606: is the place for other packages to install header files that GNU CC will
        !           607: use.  For a cross-compiler, this is the equivalent of `/usr/include'.
        !           608: When you build a cross-compiler, `fixincludes' processes any header
        !           609: files in this directory.
        !           610: 
        !           611: 
        !           612: File: gcc.info,  Node: C Extensions,  Next: C++ Extensions,  Prev: Installation,  Up: Top
        !           613: 
        !           614: Extensions to the C Language Family
        !           615: ***********************************
        !           616: 
        !           617:    GNU C provides several language features not found in ANSI standard
        !           618: C.  (The `-pedantic' option directs GNU CC to print a warning message if
        !           619: any of these features is used.)  To test for the availability of these
        !           620: features in conditional compilation, check for a predefined macro
        !           621: `__GNUC__', which is always defined under GNU CC.
        !           622: 
        !           623:    These extensions are available in C and in the languages derived from
        !           624: it, C++ and Objective C.  *Note Extensions to the C++ Language: C++
        !           625: Extensions, for extensions that apply *only* to C++.
        !           626: 
        !           627: * Menu:
        !           628: 
        !           629: * Statement Exprs::     Putting statements and declarations inside expressions.
        !           630: * Local Labels::        Labels local to a statement-expression.
        !           631: * Labels as Values::    Getting pointers to labels, and computed gotos.
        !           632: * Nested Functions::    As in Algol and Pascal, lexical scoping of functions.
        !           633: * Constructing Calls:: Dispatching a call to another function.
        !           634: * Naming Types::        Giving a name to the type of some expression.
        !           635: * Typeof::              `typeof': referring to the type of an expression.
        !           636: * Lvalues::             Using `?:', `,' and casts in lvalues.
        !           637: * Conditionals::        Omitting the middle operand of a `?:' expression.
        !           638: * Long Long::          Double-word integers--`long long int'.
        !           639: * Complex::             Data types for complex numbers.
        !           640: * Zero Length::         Zero-length arrays.
        !           641: * Variable Length::     Arrays whose length is computed at run time.
        !           642: * Macro Varargs::      Macros with variable number of arguments.
        !           643: * Subscripting::        Any array can be subscripted, even if not an lvalue.
        !           644: * Pointer Arith::       Arithmetic on `void'-pointers and function pointers.
        !           645: * Initializers::        Non-constant initializers.
        !           646: * Constructors::        Constructor expressions give structures, unions
        !           647:                          or arrays as values.
        !           648: * Labeled Elements::   Labeling elements of initializers.
        !           649: * Cast to Union::       Casting to union type from any member of the union.
        !           650: * Case Ranges::                `case 1 ... 9' and such.
        !           651: * Function Attributes:: Declaring that functions have no side effects,
        !           652:                          or that they can never return.
        !           653: * Function Prototypes:: Prototype declarations and old-style definitions.
        !           654: * Dollar Signs::        Dollar sign is allowed in identifiers.
        !           655: * Character Escapes::   `\e' stands for the character ESC.
        !           656: * Variable Attributes::        Specifying attributes of variables.
        !           657: * Alignment::           Inquiring about the alignment of a type or variable.
        !           658: * Inline::              Defining inline functions (as fast as macros).
        !           659: * Extended Asm::        Assembler instructions with C expressions as operands.
        !           660:                          (With them you can define "built-in" functions.)
        !           661: * Asm Labels::          Specifying the assembler name to use for a C symbol.
        !           662: * Explicit Reg Vars::   Defining variables residing in specified registers.
        !           663: * Alternate Keywords::  `__const__', `__asm__', etc., for header files.
        !           664: * Incomplete Enums::    `enum foo;', with details to follow.
        !           665: * Function Names::     Printable strings which are the name of the current
        !           666:                         function.
        !           667: 
        !           668: 
        !           669: File: gcc.info,  Node: Statement Exprs,  Next: Local Labels,  Up: C Extensions
        !           670: 
        !           671: Statements and Declarations in Expressions
        !           672: ==========================================
        !           673: 
        !           674:    A compound statement enclosed in parentheses may appear as an
        !           675: expression in GNU C.  This allows you to use loops, switches, and local
        !           676: variables within an expression.
        !           677: 
        !           678:    Recall that a compound statement is a sequence of statements
        !           679: surrounded by braces; in this construct, parentheses go around the
        !           680: braces.  For example:
        !           681: 
        !           682:      ({ int y = foo (); int z;
        !           683:         if (y > 0) z = y;
        !           684:         else z = - y;
        !           685:         z; })
        !           686: 
        !           687: is a valid (though slightly more complex than necessary) expression for
        !           688: the absolute value of `foo ()'.
        !           689: 
        !           690:    The last thing in the compound statement should be an expression
        !           691: followed by a semicolon; the value of this subexpression serves as the
        !           692: value of the entire construct.  (If you use some other kind of statement
        !           693: last within the braces, the construct has type `void', and thus
        !           694: effectively no value.)
        !           695: 
        !           696:    This feature is especially useful in making macro definitions "safe"
        !           697: (so that they evaluate each operand exactly once).  For example, the
        !           698: "maximum" function is commonly defined as a macro in standard C as
        !           699: follows:
        !           700: 
        !           701:      #define max(a,b) ((a) > (b) ? (a) : (b))
        !           702: 
        !           703: But this definition computes either A or B twice, with bad results if
        !           704: the operand has side effects.  In GNU C, if you know the type of the
        !           705: operands (here let's assume `int'), you can define the macro safely as
        !           706: follows:
        !           707: 
        !           708:      #define maxint(a,b) \
        !           709:        ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
        !           710: 
        !           711:    Embedded statements are not allowed in constant expressions, such as
        !           712: the value of an enumeration constant, the width of a bit field, or the
        !           713: initial value of a static variable.
        !           714: 
        !           715:    If you don't know the type of the operand, you can still do this,
        !           716: but you must use `typeof' (*note Typeof::.) or type naming (*note
        !           717: Naming Types::.).
        !           718: 
        !           719: 
        !           720: File: gcc.info,  Node: Local Labels,  Next: Labels as Values,  Prev: Statement Exprs,  Up: C Extensions
        !           721: 
        !           722: Locally Declared Labels
        !           723: =======================
        !           724: 
        !           725:    Each statement expression is a scope in which "local labels" can be
        !           726: declared.  A local label is simply an identifier; you can jump to it
        !           727: with an ordinary `goto' statement, but only from within the statement
        !           728: expression it belongs to.
        !           729: 
        !           730:    A local label declaration looks like this:
        !           731: 
        !           732:      __label__ LABEL;
        !           733: 
        !           734: or
        !           735: 
        !           736:      __label__ LABEL1, LABEL2, ...;
        !           737: 
        !           738:    Local label declarations must come at the beginning of the statement
        !           739: expression, right after the `({', before any ordinary declarations.
        !           740: 
        !           741:    The label declaration defines the label *name*, but does not define
        !           742: the label itself.  You must do this in the usual way, with `LABEL:',
        !           743: within the statements of the statement expression.
        !           744: 
        !           745:    The local label feature is useful because statement expressions are
        !           746: often used in macros.  If the macro contains nested loops, a `goto' can
        !           747: be useful for breaking out of them.  However, an ordinary label whose
        !           748: scope is the whole function cannot be used: if the macro can be
        !           749: expanded several times in one function, the label will be multiply
        !           750: defined in that function.  A local label avoids this problem.  For
        !           751: example:
        !           752: 
        !           753:      #define SEARCH(array, target)                     \
        !           754:      ({                                               \
        !           755:        __label__ found;                                \
        !           756:        typeof (target) _SEARCH_target = (target);      \
        !           757:        typeof (*(array)) *_SEARCH_array = (array);     \
        !           758:        int i, j;                                       \
        !           759:        int value;                                      \
        !           760:        for (i = 0; i < max; i++)                       \
        !           761:          for (j = 0; j < max; j++)                     \
        !           762:            if (_SEARCH_array[i][j] == _SEARCH_target)  \
        !           763:              { value = i; goto found; }              \
        !           764:        value = -1;                                     \
        !           765:       found:                                           \
        !           766:        value;                                          \
        !           767:      })
        !           768: 
        !           769: 
        !           770: File: gcc.info,  Node: Labels as Values,  Next: Nested Functions,  Prev: Local Labels,  Up: C Extensions
        !           771: 
        !           772: Labels as Values
        !           773: ================
        !           774: 
        !           775:    You can get the address of a label defined in the current function
        !           776: (or a containing function) with the unary operator `&&'.  The value has
        !           777: type `void *'.  This value is a constant and can be used wherever a
        !           778: constant of that type is valid.  For example:
        !           779: 
        !           780:      void *ptr;
        !           781:      ...
        !           782:      ptr = &&foo;
        !           783: 
        !           784:    To use these values, you need to be able to jump to one.  This is
        !           785: done with the computed goto statement(1), `goto *EXP;'.  For example,
        !           786: 
        !           787:      goto *ptr;
        !           788: 
        !           789: Any expression of type `void *' is allowed.
        !           790: 
        !           791:    One way of using these constants is in initializing a static array
        !           792: that will serve as a jump table:
        !           793: 
        !           794:      static void *array[] = { &&foo, &&bar, &&hack };
        !           795: 
        !           796:    Then you can select a label with indexing, like this:
        !           797: 
        !           798:      goto *array[i];
        !           799: 
        !           800: Note that this does not check whether the subscript is in bounds--array
        !           801: indexing in C never does that.
        !           802: 
        !           803:    Such an array of label values serves a purpose much like that of the
        !           804: `switch' statement.  The `switch' statement is cleaner, so use that
        !           805: rather than an array unless the problem does not fit a `switch'
        !           806: statement very well.
        !           807: 
        !           808:    Another use of label values is in an interpreter for threaded code.
        !           809: The labels within the interpreter function can be stored in the
        !           810: threaded code for super-fast dispatching.
        !           811: 
        !           812:    You can use this mechanism to jump to code in a different function.
        !           813: If you do that, totally unpredictable things will happen.  The best way
        !           814: to avoid this is to store the label address only in automatic variables
        !           815: and never pass it as an argument.
        !           816: 
        !           817:    ---------- Footnotes ----------
        !           818: 
        !           819:    (1)  The analogous feature in Fortran is called an assigned goto,
        !           820: but that name seems inappropriate in C, where one can do more than
        !           821: simply store label addresses in label variables.
        !           822: 
        !           823: 
        !           824: File: gcc.info,  Node: Nested Functions,  Next: Constructing Calls,  Prev: Labels as Values,  Up: C Extensions
        !           825: 
        !           826: Nested Functions
        !           827: ================
        !           828: 
        !           829:    A "nested function" is a function defined inside another function.
        !           830: (Nested functions are not supported for GNU C++.)  The nested function's
        !           831: name is local to the block where it is defined.  For example, here we
        !           832: define a nested function named `square', and call it twice:
        !           833: 
        !           834:      foo (double a, double b)
        !           835:      {
        !           836:        double square (double z) { return z * z; }
        !           837:      
        !           838:        return square (a) + square (b);
        !           839:      }
        !           840: 
        !           841:    The nested function can access all the variables of the containing
        !           842: function that are visible at the point of its definition.  This is
        !           843: called "lexical scoping".  For example, here we show a nested function
        !           844: which uses an inherited variable named `offset':
        !           845: 
        !           846:      bar (int *array, int offset, int size)
        !           847:      {
        !           848:        int access (int *array, int index)
        !           849:          { return array[index + offset]; }
        !           850:        int i;
        !           851:        ...
        !           852:        for (i = 0; i < size; i++)
        !           853:          ... access (array, i) ...
        !           854:      }
        !           855: 
        !           856:    Nested function definitions are permitted within functions in the
        !           857: places where variable definitions are allowed; that is, in any block,
        !           858: before the first statement in the block.
        !           859: 
        !           860:    It is possible to call the nested function from outside the scope of
        !           861: its name by storing its address or passing the address to another
        !           862: function:
        !           863: 
        !           864:      hack (int *array, int size)
        !           865:      {
        !           866:        void store (int index, int value)
        !           867:          { array[index] = value; }
        !           868:      
        !           869:        intermediate (store, size);
        !           870:      }
        !           871: 
        !           872:    Here, the function `intermediate' receives the address of `store' as
        !           873: an argument.  If `intermediate' calls `store', the arguments given to
        !           874: `store' are used to store into `array'.  But this technique works only
        !           875: so long as the containing function (`hack', in this example) does not
        !           876: exit.  If you try to call the nested function through its address after
        !           877: the containing function has exited, all hell will break loose.
        !           878: 
        !           879:    GNU CC implements taking the address of a nested function using a
        !           880: technique called "trampolines".  A paper describing them is available
        !           881: from `maya.idiap.ch' in directory `pub/tmb', file `usenix88-lexic.ps.Z'.
        !           882: 
        !           883:    A nested function can jump to a label inherited from a containing
        !           884: function, provided the label was explicitly declared in the containing
        !           885: function (*note Local Labels::.).  Such a jump returns instantly to the
        !           886: containing function, exiting the nested function which did the `goto'
        !           887: and any intermediate functions as well.  Here is an example:
        !           888: 
        !           889:      bar (int *array, int offset, int size)
        !           890:      {
        !           891:        __label__ failure;
        !           892:        int access (int *array, int index)
        !           893:          {
        !           894:            if (index > size)
        !           895:              goto failure;
        !           896:            return array[index + offset];
        !           897:          }
        !           898:        int i;
        !           899:        ...
        !           900:        for (i = 0; i < size; i++)
        !           901:          ... access (array, i) ...
        !           902:        ...
        !           903:        return 0;
        !           904:      
        !           905:       /* Control comes here from `access'
        !           906:          if it detects an error.  */
        !           907:       failure:
        !           908:        return -1;
        !           909:      }
        !           910: 
        !           911:    A nested function always has internal linkage.  Declaring one with
        !           912: `extern' is erroneous.  If you need to declare the nested function
        !           913: before its definition, use `auto' (which is otherwise meaningless for
        !           914: function declarations).
        !           915: 
        !           916:      bar (int *array, int offset, int size)
        !           917:      {
        !           918:        __label__ failure;
        !           919:        auto int access (int *, int);
        !           920:        ...
        !           921:        int access (int *array, int index)
        !           922:          {
        !           923:            if (index > size)
        !           924:              goto failure;
        !           925:            return array[index + offset];
        !           926:          }
        !           927:        ...
        !           928:      }
        !           929: 
        !           930: 
        !           931: File: gcc.info,  Node: Constructing Calls,  Next: Naming Types,  Prev: Nested Functions,  Up: C Extensions
        !           932: 
        !           933: Constructing Function Calls
        !           934: ===========================
        !           935: 
        !           936:    Using the built-in functions described below, you can record the
        !           937: arguments a function received, and call another function with the same
        !           938: arguments, without knowing the number or types of the arguments.
        !           939: 
        !           940:    You can also record the return value of that function call, and
        !           941: later return that value, without knowing what data type the function
        !           942: tried to return (as long as your caller expects that data type).
        !           943: 
        !           944: `__builtin_apply_args ()'
        !           945:      This built-in function returns a pointer of type `void *' to data
        !           946:      describing how to perform a call with the same arguments as were
        !           947:      passed to the current function.
        !           948: 
        !           949:      The function saves the arg pointer register, structure value
        !           950:      address, and all registers that might be used to pass arguments to
        !           951:      a function into a block of memory allocated on the stack.  Then it
        !           952:      returns the address of that block.
        !           953: 
        !           954: `__builtin_apply (FUNCTION, ARGUMENTS, SIZE)'
        !           955:      This built-in function invokes FUNCTION (type `void (*)()') with a
        !           956:      copy of the parameters described by ARGUMENTS (type `void *') and
        !           957:      SIZE (type `int').
        !           958: 
        !           959:      The value of ARGUMENTS should be the value returned by
        !           960:      `__builtin_apply_args'.  The argument SIZE specifies the size of
        !           961:      the stack argument data, in bytes.
        !           962: 
        !           963:      This function returns a pointer of type `void *' to data describing
        !           964:      how to return whatever value was returned by FUNCTION.  The data
        !           965:      is saved in a block of memory allocated on the stack.
        !           966: 
        !           967:      It is not always simple to compute the proper value for SIZE.  The
        !           968:      value is used by `__builtin_apply' to compute the amount of data
        !           969:      that should be pushed on the stack and copied from the incoming
        !           970:      argument area.
        !           971: 
        !           972: `__builtin_return (RESULT)'
        !           973:      This built-in function returns the value described by RESULT from
        !           974:      the containing function.  You should specify, for RESULT, a value
        !           975:      returned by `__builtin_apply'.
        !           976: 
        !           977: 
        !           978: File: gcc.info,  Node: Naming Types,  Next: Typeof,  Prev: Constructing Calls,  Up: C Extensions
        !           979: 
        !           980: Naming an Expression's Type
        !           981: ===========================
        !           982: 
        !           983:    You can give a name to the type of an expression using a `typedef'
        !           984: declaration with an initializer.  Here is how to define NAME as a type
        !           985: name for the type of EXP:
        !           986: 
        !           987:      typedef NAME = EXP;
        !           988: 
        !           989:    This is useful in conjunction with the statements-within-expressions
        !           990: feature.  Here is how the two together can be used to define a safe
        !           991: "maximum" macro that operates on any arithmetic type:
        !           992: 
        !           993:      #define max(a,b) \
        !           994:        ({typedef _ta = (a), _tb = (b);  \
        !           995:          _ta _a = (a); _tb _b = (b);     \
        !           996:          _a > _b ? _a : _b; })
        !           997: 
        !           998:    The reason for using names that start with underscores for the local
        !           999: variables is to avoid conflicts with variable names that occur within
        !          1000: the expressions that are substituted for `a' and `b'.  Eventually we
        !          1001: hope to design a new form of declaration syntax that allows you to
        !          1002: declare variables whose scopes start only after their initializers;
        !          1003: this will be a more reliable way to prevent such conflicts.
        !          1004: 
        !          1005: 
        !          1006: File: gcc.info,  Node: Typeof,  Next: Lvalues,  Prev: Naming Types,  Up: C Extensions
        !          1007: 
        !          1008: Referring to a Type with `typeof'
        !          1009: =================================
        !          1010: 
        !          1011:    Another way to refer to the type of an expression is with `typeof'.
        !          1012: The syntax of using of this keyword looks like `sizeof', but the
        !          1013: construct acts semantically like a type name defined with `typedef'.
        !          1014: 
        !          1015:    There are two ways of writing the argument to `typeof': with an
        !          1016: expression or with a type.  Here is an example with an expression:
        !          1017: 
        !          1018:      typeof (x[0](1))
        !          1019: 
        !          1020: This assumes that `x' is an array of functions; the type described is
        !          1021: that of the values of the functions.
        !          1022: 
        !          1023:    Here is an example with a typename as the argument:
        !          1024: 
        !          1025:      typeof (int *)
        !          1026: 
        !          1027: Here the type described is that of pointers to `int'.
        !          1028: 
        !          1029:    If you are writing a header file that must work when included in
        !          1030: ANSI C programs, write `__typeof__' instead of `typeof'.  *Note
        !          1031: Alternate Keywords::.
        !          1032: 
        !          1033:    A `typeof'-construct can be used anywhere a typedef name could be
        !          1034: used.  For example, you can use it in a declaration, in a cast, or
        !          1035: inside of `sizeof' or `typeof'.
        !          1036: 
        !          1037:    * This declares `y' with the type of what `x' points to.
        !          1038: 
        !          1039:           typeof (*x) y;
        !          1040: 
        !          1041:    * This declares `y' as an array of such values.
        !          1042: 
        !          1043:           typeof (*x) y[4];
        !          1044: 
        !          1045:    * This declares `y' as an array of pointers to characters:
        !          1046: 
        !          1047:           typeof (typeof (char *)[4]) y;
        !          1048: 
        !          1049:      It is equivalent to the following traditional C declaration:
        !          1050: 
        !          1051:           char *y[4];
        !          1052: 
        !          1053:      To see the meaning of the declaration using `typeof', and why it
        !          1054:      might be a useful way to write, let's rewrite it with these macros:
        !          1055: 
        !          1056:           #define pointer(T)  typeof(T *)
        !          1057:           #define array(T, N) typeof(T [N])
        !          1058: 
        !          1059:      Now the declaration can be rewritten this way:
        !          1060: 
        !          1061:           array (pointer (char), 4) y;
        !          1062: 
        !          1063:      Thus, `array (pointer (char), 4)' is the type of arrays of 4
        !          1064:      pointers to `char'.
        !          1065: 
        !          1066: 
        !          1067: File: gcc.info,  Node: Lvalues,  Next: Conditionals,  Prev: Typeof,  Up: C Extensions
        !          1068: 
        !          1069: Generalized Lvalues
        !          1070: ===================
        !          1071: 
        !          1072:    Compound expressions, conditional expressions and casts are allowed
        !          1073: as lvalues provided their operands are lvalues.  This means that you
        !          1074: can take their addresses or store values into them.
        !          1075: 
        !          1076:    For example, a compound expression can be assigned, provided the last
        !          1077: expression in the sequence is an lvalue.  These two expressions are
        !          1078: equivalent:
        !          1079: 
        !          1080:      (a, b) += 5
        !          1081:      a, (b += 5)
        !          1082: 
        !          1083:    Similarly, the address of the compound expression can be taken.
        !          1084: These two expressions are equivalent:
        !          1085: 
        !          1086:      &(a, b)
        !          1087:      a, &b
        !          1088: 
        !          1089:    A conditional expression is a valid lvalue if its type is not void
        !          1090: and the true and false branches are both valid lvalues.  For example,
        !          1091: these two expressions are equivalent:
        !          1092: 
        !          1093:      (a ? b : c) = 5
        !          1094:      (a ? b = 5 : (c = 5))
        !          1095: 
        !          1096:    A cast is a valid lvalue if its operand is an lvalue.  A simple
        !          1097: assignment whose left-hand side is a cast works by converting the
        !          1098: right-hand side first to the specified type, then to the type of the
        !          1099: inner left-hand side expression.  After this is stored, the value is
        !          1100: converted back to the specified type to become the value of the
        !          1101: assignment.  Thus, if `a' has type `char *', the following two
        !          1102: expressions are equivalent:
        !          1103: 
        !          1104:      (int)a = 5
        !          1105:      (int)(a = (char *)(int)5)
        !          1106: 
        !          1107:    An assignment-with-arithmetic operation such as `+=' applied to a
        !          1108: cast performs the arithmetic using the type resulting from the cast,
        !          1109: and then continues as in the previous case.  Therefore, these two
        !          1110: expressions are equivalent:
        !          1111: 
        !          1112:      (int)a += 5
        !          1113:      (int)(a = (char *)(int) ((int)a + 5))
        !          1114: 
        !          1115:    You cannot take the address of an lvalue cast, because the use of its
        !          1116: address would not work out coherently.  Suppose that `&(int)f' were
        !          1117: permitted, where `f' has type `float'.  Then the following statement
        !          1118: would try to store an integer bit-pattern where a floating point number
        !          1119: belongs:
        !          1120: 
        !          1121:      *&(int)f = 1;
        !          1122: 
        !          1123:    This is quite different from what `(int)f = 1' would do--that would
        !          1124: convert 1 to floating point and store it.  Rather than cause this
        !          1125: inconsistency, we think it is better to prohibit use of `&' on a cast.
        !          1126: 
        !          1127:    If you really do want an `int *' pointer with the address of `f',
        !          1128: you can simply write `(int *)&f'.
        !          1129: 
        !          1130: 
        !          1131: File: gcc.info,  Node: Conditionals,  Next: Long Long,  Prev: Lvalues,  Up: C Extensions
        !          1132: 
        !          1133: Conditionals with Omitted Operands
        !          1134: ==================================
        !          1135: 
        !          1136:    The middle operand in a conditional expression may be omitted.  Then
        !          1137: if the first operand is nonzero, its value is the value of the
        !          1138: conditional expression.
        !          1139: 
        !          1140:    Therefore, the expression
        !          1141: 
        !          1142:      x ? : y
        !          1143: 
        !          1144: has the value of `x' if that is nonzero; otherwise, the value of `y'.
        !          1145: 
        !          1146:    This example is perfectly equivalent to
        !          1147: 
        !          1148:      x ? x : y
        !          1149: 
        !          1150: In this simple case, the ability to omit the middle operand is not
        !          1151: especially useful.  When it becomes useful is when the first operand
        !          1152: does, or may (if it is a macro argument), contain a side effect.  Then
        !          1153: repeating the operand in the middle would perform the side effect
        !          1154: twice.  Omitting the middle operand uses the value already computed
        !          1155: without the undesirable effects of recomputing it.
        !          1156: 
        !          1157: 
        !          1158: File: gcc.info,  Node: Long Long,  Next: Complex,  Prev: Conditionals,  Up: C Extensions
        !          1159: 
        !          1160: Double-Word Integers
        !          1161: ====================
        !          1162: 
        !          1163:    GNU C supports data types for integers that are twice as long as
        !          1164: `long int'.  Simply write `long long int' for a signed integer, or
        !          1165: `unsigned long long int' for an unsigned integer.  To make an integer
        !          1166: constant of type `long long int', add the suffix `LL' to the integer.
        !          1167: To make an integer constant of type `unsigned long long int', add the
        !          1168: suffix `ULL' to the integer.
        !          1169: 
        !          1170:    You can use these types in arithmetic like any other integer types.
        !          1171: Addition, subtraction, and bitwise boolean operations on these types
        !          1172: are open-coded on all types of machines.  Multiplication is open-coded
        !          1173: if the machine supports fullword-to-doubleword a widening multiply
        !          1174: instruction.  Division and shifts are open-coded only on machines that
        !          1175: provide special support.  The operations that are not open-coded use
        !          1176: special library routines that come with GNU CC.
        !          1177: 
        !          1178:    There may be pitfalls when you use `long long' types for function
        !          1179: arguments, unless you declare function prototypes.  If a function
        !          1180: expects type `int' for its argument, and you pass a value of type `long
        !          1181: long int', confusion will result because the caller and the subroutine
        !          1182: will disagree about the number of bytes for the argument.  Likewise, if
        !          1183: the function expects `long long int' and you pass `int'.  The best way
        !          1184: to avoid such problems is to use prototypes.
        !          1185: 
        !          1186: 
        !          1187: File: gcc.info,  Node: Complex,  Next: Zero Length,  Prev: Long Long,  Up: C Extensions
        !          1188: 
        !          1189: Complex Numbers
        !          1190: ===============
        !          1191: 
        !          1192:    GNU C supports complex data types.  You can declare both complex
        !          1193: integer types and complex floating types, using the keyword
        !          1194: `__complex__'.
        !          1195: 
        !          1196:    For example, `__complex__ double x;' declares `x' as a variable
        !          1197: whose real part and imaginary part are both of type `double'.
        !          1198: `__complex__ short int y;' declares `y' to have real and imaginary
        !          1199: parts of type `short int'; this is not likely to be useful, but it
        !          1200: shows that the set of complex types is complete.
        !          1201: 
        !          1202:    To write a constant with a complex data type, use the suffix `i' or
        !          1203: `j' (either one; they are equivalent).  For example, `2.5fi' has type
        !          1204: `__complex__ float' and `3i' has type `__complex__ int'.  Such a
        !          1205: constant always has a pure imaginary value, but you can form any
        !          1206: complex value you like by adding one to a real constant.
        !          1207: 
        !          1208:    To extract the real part of a complex-valued expression EXP, write
        !          1209: `__real__ EXP'.  Likewise, use `__imag__' to extract the imaginary part.
        !          1210: 
        !          1211:    The operator `~' performs complex conjugation when used on a value
        !          1212: with a complex type.
        !          1213: 
        !          1214:    GNU CC can allocate complex automatic variables in a noncontiguous
        !          1215: fashion; it's even possible for the real part to be in a register while
        !          1216: the imaginary part is on the stack (or vice-versa).  None of the
        !          1217: supported debugging info formats has a way to represent noncontiguous
        !          1218: allocation like this, so GNU CC describes a noncontiguous complex
        !          1219: variable as if it were two separate variables of noncomplex type.  If
        !          1220: the variable's actual name is `foo', the two fictitious variables are
        !          1221: named `foo$real' and `foo$imag'.  You can examine and set these two
        !          1222: fictitious variables with your debugger.
        !          1223: 
        !          1224:    A future version of GDB will know how to recognize such pairs and
        !          1225: treat them as a single variable with a complex type.
        !          1226: 
        !          1227: 
        !          1228: File: gcc.info,  Node: Zero Length,  Next: Variable Length,  Prev: Complex,  Up: C Extensions
        !          1229: 
        !          1230: Arrays of Length Zero
        !          1231: =====================
        !          1232: 
        !          1233:    Zero-length arrays are allowed in GNU C.  They are very useful as
        !          1234: the last element of a structure which is really a header for a
        !          1235: variable-length object:
        !          1236: 
        !          1237:      struct line {
        !          1238:        int length;
        !          1239:        char contents[0];
        !          1240:      };
        !          1241:      
        !          1242:      {
        !          1243:        struct line *thisline = (struct line *)
        !          1244:          malloc (sizeof (struct line) + this_length);
        !          1245:        thisline->length = this_length;
        !          1246:      }
        !          1247: 
        !          1248:    In standard C, you would have to give `contents' a length of 1, which
        !          1249: means either you waste space or complicate the argument to `malloc'.
        !          1250: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.