|
|
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.2 root 6: Copyright (C) 1988, 1989 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
1.1.1.3 ! root 14: that the sections entitled ``GNU General Public License'' and
! 15: ``Protect Your Freedom--Fight `Look And Feel''' are included exactly
! 16: as in the original, and provided that the entire resulting derived
! 17: work is distributed under the terms of a permission notice identical
! 18: to this one.
1.1 root 19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
1.1.1.3 ! root 22: versions, except that the sections entitled ``GNU General Public
! 23: License'' and ``Protect Your Freedom--Fight `Look And Feel''' and
! 24: this permission notice may be included in translations approved by
! 25: the Free Software Foundation instead of in the original English.
1.1 root 26:
27:
28:
1.1.1.3 ! root 29: File: gcc.info, Node: Installation, Next: Trouble, Prev: Options, Up: Top
1.1.1.2 root 30:
1.1.1.3 ! root 31: Installing GNU CC
! 32: *****************
! 33:
! 34: Here is the procedure for installing GNU CC on a Unix system.
! 35:
! 36: * Menu:
1.1.1.2 root 37:
1.1.1.3 ! root 38: * Other Dir:: Compiling in a separate directory (not where the source is).
! 39: * Sun Install:: See below for installation on the Sun.
! 40: * 3B1 Install:: See below for installation on the 3B1.
! 41: * VMS Install:: See below for installation on VMS.
! 42: * HPUX Install:: See below for installation on HPUX.
! 43:
! 44: 1. Edit `Makefile'. If you are using HPUX, or any form of system
! 45: V, you must make a few changes described in comments at the
! 46: beginning of the file. Genix requires changes also, and so does
! 47: the Pyramid.
! 48:
! 49: 2. On a Sequent system, go to the Berkeley universe.
! 50:
! 51: 3. Choose configuration files. The easy way to do this is to run
! 52: the command file `config.gcc' with a single argument, which
! 53: specifies the type of machine (and in some cases which operating
! 54: system).
! 55:
! 56: Here is a list of the possible arguments:
! 57:
! 58: `vax'
! 59: Vaxes running BSD.
! 60:
! 61: `vms'
! 62: Vaxes running VMS.
! 63:
! 64: `vax-sysv'
! 65: Vaxes running system V.
! 66:
! 67: `i386-sysv'
! 68: Intel 386 PCs running system V.
! 69:
! 70: `i386-sysv-gas'
! 71: Intel 386 PCs running system V, using the GNU assembler and
! 72: GNU linker.
! 73:
! 74: `sequent-i386'
! 75: Sequent with Intel 386 processors.
! 76:
! 77: `i386-aix'
! 78: Intel 386 PCs or PS/2s running AIX.
! 79:
! 80: `sun2'
! 81: Sun 2 running system version 2 or 3.
! 82:
! 83: `sun3'
! 84: Sun 3 running system version 2 or 3, with 68881. Note
! 85: there we do not provide a configuration file to use an FPA
! 86: by default, because programs that establish signal handlers
! 87: for floating point traps inherently cannot work with the FPA.
! 88:
! 89: `sun3-nfp'
! 90: Sun 3 running system version 2 or 3, without 68881.
! 91:
! 92: `sun4'
! 93: Sun 4 running system version 2 or 3. *Note
! 94: Incompatibilities::, for calling convention
! 95: incompatibilities on the Sun 4 (sparc).
! 96:
! 97: `sun2-os4'
! 98: Sun 2 running system version 4.
! 99:
! 100: `sun3-os4'
! 101: Sun 3 running system version 4, with 68881.
! 102:
! 103: `sun3-nfp-os4'
! 104: Sun 3 running system version 4, without 68881.
! 105:
! 106: `sun4-os4'
! 107: Sun 4 running system version 4. *Note Incompatibilities::,
! 108: for calling convention incompatibilities on the Sun 4
! 109: (sparc).
! 110:
! 111: `sun386'
! 112: Sun 386 (``roadrunner'').
! 113:
! 114: `alliant'
! 115: Alliant FX/8 computer. Note that the standard installed C
! 116: compiler in Concentrix 5.0 has a bug which prevent it from
! 117: compiling GNU CC correctly. You can patch the compiler bug
! 118: as follows:
! 119:
! 120: cp /bin/pcc ./pcc
! 121: adb -w ./pcc - << EOF
! 122: 15f6?w 6610
! 123: EOF
! 124:
! 125: Then you must use the `-ip12' option when compiling GNU CC
! 126: with the patched compiler, as shown here:
! 127:
! 128: make CC="./pcc -ip12" CFLAGS=-w
! 129:
! 130: Note also that Alliant's version of DBX does not manage to
! 131: work with the output from GNU CC.
! 132:
! 133: `tahoe'
! 134: The tahoe computer (running BSD, and using DBX).
! 135:
! 136: `decstation'
! 137: The DEC 3100 Mips machine (``pmax''). Note that GNU CC
! 138: cannot generate debugging information in the unusual format
! 139: used on the Mips.
! 140:
! 141: `mips-sysv'
! 142: The Mips computer, RS series, with the System V environment
! 143: as default. Note that GNU CC cannot generate debugging
! 144: information in the unusual format used on the Mips.
! 145:
! 146: `mips-bsd43'
! 147: The Mips computer, RS series, with the BSD 4.3 environment
! 148: as default. Note that GNU CC cannot generate debugging
! 149: information in the unusual format used on the Mips.
! 150:
! 151: `mips'
! 152: The Mips computer, M series. Note that GNU CC cannot
! 153: generate debugging information in the unusual format used
! 154: on the Mips.
! 155:
! 156: `iris'
! 157: The Mips computer, as delivered by Iris. Note that GNU CC
! 158: cannot generate debugging information in the unusual format
! 159: used on the Mips.
! 160:
! 161: `convex-c1'
! 162: Convex C1 computer.
! 163:
! 164: `convex-c2'
! 165: Convex C2 computer.
! 166:
! 167: `pyramid'
! 168: Pyramid computer.
! 169:
! 170: `hp9k320'
! 171: HP 9000 series 300 using HPUX assembler. Note there is no
! 172: support in GNU CC for HP's debugger; thus, `-g' is not
! 173: available in this configuration.
! 174:
! 175: `hp9k320-gas'
! 176: HP 9000 series 300 using GNU assembler, linker and debugger.
! 177: This requires the HP-adapt package, which is available
! 178: along with the GNU linker as part of the ``binutils''
! 179: distribution. This is on the GNU CC distribution tape.
! 180:
! 181: `hp9k320-old'
! 182: HP 9000 series 300 using HPUX assembler, in operating
! 183: system versions older than 6.5. Note there is no support
! 184: in GNU CC for HP's debugger; thus, `-g' is not available in
! 185: this configuration.
! 186:
! 187: `hp9k320-bsd'
! 188: HP 9000 series 300 running BSD.
! 189:
! 190: `isi68'
! 191: ISI 68000 or 68020 system with a 68881.
! 192:
! 193: `isi68-nfp'
! 194: ISI 68000 or 68020 system without a 68881.
! 195:
! 196: `news800'
! 197: Sony NEWS 68020 system.
! 198:
! 199: `next'
! 200: NeXT system.
! 201:
! 202: `altos'
! 203: Altos 3068. Note that you must use the GNU assembler,
! 204: linker and debugger, with COFF-encapsulation. Also, you
! 205: must fix a kernel bug. Details in the file `ALTOS-README'.
! 206:
! 207: `3b1'
! 208: AT&T 3b1, a.k.a. 7300 PC. Note that special procedures are
! 209: needed to compile GNU CC with this machine's standard C
! 210: compiler, due to bugs in that compiler. *Note 3b1
! 211: Install::. You can bootstrap it more easily with previous
! 212: versions of GNU CC if you have them.
! 213:
! 214: `3b1-gas'
! 215: AT&T 3b1 using the GNU assembler.
! 216:
! 217: `sequent-ns32k'
! 218: Sequent containing ns32000 processors.
! 219:
! 220: `encore'
! 221: Encore ns32000 system.
! 222:
! 223: `genix'
! 224: National Semiconductor ns32000 system.
! 225:
! 226: `88000'
! 227: Motorola 88000 processor. This port is not finished.
! 228:
! 229: Here we spell out what files need to be set up:
! 230:
! 231: * Make a symbolic link named `config.h' to the top-level
! 232: config file for the machine you are using (*note
! 233: Config::.). This file is responsible for defining
! 234: information about the host machine. It includes `tm.h'.
! 235:
! 236: The file is located in the subdirectory `config'. Its name
! 237: should be `xm-MACHINE.h', with these exceptions:
! 238:
! 239: `xm-vms.h'
! 240: for vaxen running VMS.
! 241:
! 242: `xm-vaxv.h'
! 243: for vaxen running system V.
! 244:
! 245: `xm-i386v.h'
! 246: for Intel 80386's running system V.
! 247:
! 248: `xm-sun386i.h'
! 249: for Sun roadrunner running any version of the
! 250: operating system.
! 251:
! 252: `xm-hp9k320.h'
! 253: for the HP 9000 series 300.
! 254:
! 255: `xm-genix.h'
! 256: for the ns32000 running Genix
! 257:
! 258: If your system does not support symbolic links, you might
! 259: want to set up `config.h' to contain a `#include' command
! 260: which refers to the appropriate file.
! 261:
! 262: * Make a symbolic link named `tm.h' to the
! 263: machine-description macro file for your machine. It should
! 264: be in the subdirectory `config' and its name should be
! 265: `tm-MACHINE.h'.
! 266:
! 267: If your system is a 68000, don't use the file `tm-m68k.h'
! 268: directly. Instead, use one of these files:
! 269:
! 270: `tm-sun3.h'
! 271: for Sun 3 machines with 68881.
! 272:
! 273: `tm-sun3-nfp.h'
! 274: for Sun 3 machines with no hardware floating point.
! 275:
! 276: `tm-sun3os3.h'
! 277: for Sun 3 machines with 68881, running Sunos version 3.
! 278:
! 279: `tm-sun3os3nf.h'
! 280: for Sun 3 machines with no hardware floating point,
! 281: running Sunos version 3.
! 282:
! 283: `tm-sun2.h'
! 284: for Sun 2 machines.
! 285:
! 286: `tm-3b1.h'
! 287: for AT&T 3b1 (aka 7300 Unix PC).
! 288:
! 289: `tm-isi68.h'
! 290: for Integrated Solutions systems. This file assumes
! 291: you use the GNU assembler.
! 292:
! 293: `tm-isi68-nfp.h'
! 294: for Integrated Solutions systems without a 68881.
! 295: This file assumes you use the GNU assembler.
! 296:
! 297: `tm-news800.h'
! 298: for Sony NEWS systems.
! 299:
! 300: `tm-hp9k320.h'
! 301: for HPUX systems, if you are using GNU CC with the
! 302: system's assembler and linker.
! 303:
! 304: `tm-hp9k320g.h'
! 305: for HPUX systems, if you are using the GNU assembler,
! 306: linker and other utilities. Not all of the pieces of
! 307: GNU software needed for this mode of operation are as
! 308: yet in distribution; full instructions will appear
! 309: here in the future.
! 310:
! 311: For the vax, use `tm-vax.h' on BSD Unix, `tm-vaxv.h' on
! 312: system V, or `tm-vms.h' on VMS.
! 313:
! 314: For the Motorola 88000, use `tm-m88k.h'. The support for
! 315: the 88000 does not currently work; it requires extensive
! 316: changes which we hope to reconcile in version 2.
! 317:
! 318: For the 80386, don't use `tm-i386.h' directly. Use
! 319: `tm-i386v.h' if the target machine is running system V,
! 320: `tm-i386gas.h' if it is running system V but you are using
! 321: the GNU assembler and linker, `tm-seq386.h' for a Sequent
! 322: 386 system, or `tm-compaq.h' for a Compaq, or
! 323: `tm-sun386i.h' for a Sun 386 system.
! 324:
! 325: For the Mips computer, there are five choices: `tm-mips.h'
! 326: for the M series, `tm-mips-bsd.h' for the RS series with
! 327: BSD, `tm-mips-sysv.h' for the RS series with System V,
! 328: `tm-iris.h' for the Iris version of the machine, and
! 329: `tm-decstatn.h' for the Decstation.
! 330:
! 331: For the 32000, use `tm-sequent.h' if you are using a
! 332: Sequent machine, or `tm-encore.h' for an Encore machine, or
! 333: `tm-genix.h' if you are using Genix version 3; otherwise,
! 334: perhaps `tm-ns32k.h' will work for you.
! 335:
! 336: Note that Genix has bugs in `alloca' and `malloc'; you must
! 337: get the compiled versions of these from GNU Emacs and edit
! 338: GNU CC's `Makefile' to use them.
! 339:
! 340: Note that Encore systems are supported only under BSD.
! 341:
! 342: For Sparc (Sun 4) machines, use `tm-sparc.h' with operating
! 343: system version 4, and `tm-sun4os3.h' with system version 3.
! 344:
! 345: * Make a symbolic link named `md' to the machine description
! 346: pattern file. It should be in the `config' subdirectory
! 347: and its name should be `MACHINE.md'; but MACHINE is often
! 348: not the same as the name used in the `tm.h' file because
! 349: the `md' files are more general.
! 350:
! 351: * Make a symbolic link named `aux-output.c' to the output
! 352: subroutine file for your machine. It should be in the
! 353: `config' subdirectory and its name should be `out-MACHINE.c'.
! 354:
! 355: 4. Make sure the Bison parser generator is installed. (This is
! 356: unnecessary if the Bison output files `c-parse.tab.c' and
! 357: `cexp.c' are more recent than `c-parse.y' and `cexp.y' and you
! 358: do not plan to change the `.y' files.)
! 359:
! 360: Bison versions older than Sept 8, 1988 will produce incorrect
! 361: output for `c-parse.tab.c'.
! 362:
! 363: 5. Build the compiler. Just type `make' in the compiler directory.
! 364:
! 365: Ignore any warnings you may see about ``statement not reached''
! 366: in the `insn-emit.c'; they are normal. Any other compilation
! 367: errors may represent bugs in the port to your machine or
! 368: operating system, and should be investigated and reported (*note
! 369: Bugs::.).
! 370:
! 371: Some commercial compilers fail to compile GNU CC because they
! 372: have bugs or limitations. For example, the Microsoft compiler
! 373: is said to run out of macro space. Some Ultrix compilers run
! 374: out of expression space; then you need to break up the statement
! 375: where the problem happens.
! 376:
! 377: 6. If you are using COFF-encapsulation, you must convert `gnulib'
! 378: to a GNU-format library at this point. See the file
! 379: `README-ENCAP' in the directory containing the GNU binary file
! 380: utilities, for directions.
! 381:
! 382: 7. Move the first-stage object files and executables into a
! 383: subdirectory with this command:
! 384:
! 385: make stage1
! 386:
! 387: The files are moved into a subdirectory named `stage1'. Once
! 388: installation is complete, you may wish to delete these files
! 389: with `rm -r stage1'.
! 390:
! 391: 8. Recompile the compiler with itself, with this command:
! 392:
! 393: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
! 394:
! 395: On a 68000 or 68020 system lacking floating point hardware,
! 396: unless you have selected a `tm.h' file that expects by default
! 397: that there is no such hardware, do this instead:
! 398:
! 399: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -msoft-float"
! 400:
! 401: 9. If you wish to test the compiler by compiling it with itself one
! 402: more time, do this (in C shell):
! 403:
! 404: make stage2
! 405: make CC=stage2/gcc CFLAGS="-g -O -Bstage2/"
! 406: foreach file (*.o)
! 407: cmp $file stage2/$file
! 408: end
! 409:
! 410: Aside from the `-B' option, the options should be the same as
! 411: when you made stage 2.
! 412:
! 413: The `foreach' command (written in C shell) will notify you if
! 414: any of these stage 3 object files differs from those of stage 2.
! 415: On BSD systems, any difference, no matter how innocuous,
! 416: indicates that the stage 2 compiler has compiled GNU CC
! 417: incorrectly, and is therefore a potentially serious bug which
! 418: you should investigate and report (*note Bugs::.).
! 419:
! 420: On systems that use COFF object files, bytes 5 to 8 will always
! 421: be different, since it is a timestamp. On these systems, you
! 422: can do the comparison as follows (in Bourne shell):
! 423:
! 424: for file in *.o; do
! 425: echo $file
! 426: tail +10 $file > foo1
! 427: tail +10 stage2/$file > foo2
! 428: cmp foo1 foo2
! 429: done
! 430:
! 431: 10. Install the compiler driver, the compiler's passes and run-time
! 432: support. You can use the following command:
! 433:
! 434: make install
! 435:
! 436: This copies the files `cc1', `cpp' and `gnulib' to files
! 437: `gcc-cc1', `gcc-cpp' and `gcc-gnulib' in directory
! 438: `/usr/local/lib', which is where the compiler driver program
! 439: looks for them. It also copies the driver program `gcc' into
! 440: the directory `/usr/local/bin', so that it appears in typical
! 441: execution search paths.
! 442:
! 443: *Warning: there is a bug in `alloca' in the Sun library. To
! 444: avoid this bug, install the binaries of GNU CC that were
! 445: compiled by GNU CC. They use `alloca' as a built-in function
! 446: and never the one in the library.*
! 447:
! 448: *Warning: the GNU CPP may not work for `ioctl.h', `ttychars.h'
! 449: and other system header files unless the `-traditional' option
! 450: is used.* The bug is in the header files: at least on some
! 451: machines, they rely on behavior that is incompatible with ANSI
! 452: C. This behavior consists of substituting for macro argument
! 453: names when they appear inside of character constants. The
! 454: `-traditional' option tells GNU CC to behave the way these
! 455: headers expect.
! 456:
! 457: Because of this problem, you might prefer to configure GNU CC to
! 458: use the system's own C preprocessor. To do so, make the file
! 459: `/usr/local/lib/gcc-cpp' a link to `/lib/cpp'.
! 460:
! 461: Alternatively, on Sun systems and 4.3BSD at least, you can
! 462: correct the include files by running the shell script
! 463: `fixincludes'. This installs modified, corrected copies of the
! 464: files `ioctl.h', `ttychars.h' and many others, in a special
! 465: directory where only GNU CC will normally look for them. This
! 466: script will work on various systems because it chooses the files
! 467: by searching all the system headers for the problem cases that
! 468: we know about.
! 469:
! 470: If you cannot install the compiler's passes and run-time support in
! 471: `/usr/local/lib', you can alternatively use the `-B' option to
! 472: specify a prefix by which they may be found. The compiler
! 473: concatenates the prefix with the names `cpp', `cc1' and `gnulib'.
! 474: Thus, you can put the files in a directory `/usr/foo/gcc' and specify
! 475: `-B/usr/foo/gcc/' when you run GNU CC.
1.1.1.2 root 476:
1.1.1.3 ! root 477: Also, you can specify an alternative default directory for these
! 478: files by setting the Make variable `libdir' when you make GNU CC.
1.1.1.2 root 479:
480:
481:
1.1.1.3 ! root 482: File: gcc.info, Node: Other Dir, Next: Sun Install, Prev: Installation, Up: Installation
1.1.1.2 root 483:
1.1.1.3 ! root 484: Compilation in a Separate Directory
! 485: ===================================
1.1.1.2 root 486:
1.1.1.3 ! root 487: If you wish to build the object files and executables in a directory
! 488: other than the one containing the source files, here is what you must
! 489: do differently:
1.1.1.2 root 490:
1.1.1.3 ! root 491: 1. Go to that directory before running `config.gcc':
1.1.1.2 root 492:
1.1.1.3 ! root 493: mkdir gcc-sun3
! 494: cd gcc-sun3
1.1.1.2 root 495:
1.1.1.3 ! root 496: On systems that do not support symbolic links, this directory
! 497: must be on the same file system as the source code directory.
1.1.1.2 root 498:
1.1.1.3 ! root 499: 2. Specify where to find `config.gcc' when you run it:
1.1.1.2 root 500:
1.1.1.3 ! root 501: ../gcc-1.36/config.gcc ...
! 502:
! 503: 3. Specify where to find the sources, as an argument to `config.gcc':
! 504:
! 505: ../gcc-1.36/config.gcc -srcdir=../gcc-1.36 sun3
! 506:
! 507: The `-srcdir=DIR' option is not needed when the source directory
! 508: is the parent of the current directory, because `config.gcc'
! 509: detects that case automatically.
! 510:
! 511: Now, you can run `make' in that directory. You need not repeat the
! 512: configuration steps shown above, when ordinary source files change.
! 513: You must, however, run `config.gcc' again when the configuration
! 514: files change, if your system does not support symbolic links.
1.1.1.2 root 515:
516:
517:
1.1.1.3 ! root 518: File: gcc.info, Node: Sun Install, Next: 3b1 Install, Prev: Other Dir, Up: Installation
1.1.1.2 root 519:
1.1.1.3 ! root 520: Installing GNU CC on the Sun
! 521: ============================
1.1.1.2 root 522:
1.1.1.3 ! root 523: Make sure the environment variable `FLOAT_OPTION' is not set when you
! 524: compile `gnulib'. If this option were set to `f68881' when `gnulib'
! 525: is compiled, the resulting code would demand to be linked with a
! 526: special startup file and would not link properly without special
! 527: pains.
! 528:
! 529: There is a bug in `alloca' in certain versions of the Sun library.
! 530: To avoid this bug, install the binaries of GNU CC that were compiled
! 531: by GNU CC. They use `alloca' as a built-in function and never the
! 532: one in the library.
! 533:
! 534: Some versions of the Sun compiler crash when compiling GNU CC. The
! 535: problem is a segmentation fault in cpp.
! 536:
! 537: This problem seems to be due to the bulk of data in the environment
! 538: variables. You may be able to avoid it by using the following
! 539: command to compile GNU CC with Sun CC:
1.1.1.2 root 540:
1.1.1.3 ! root 541: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
1.1.1.2 root 542:
543:
544:
1.1.1.3 ! root 545: File: gcc.info, Node: 3b1 Install, Next: VMS Install, Prev: Sun Install, Up: Installation
! 546:
! 547: Installing GNU CC on the 3b1
! 548: ============================
! 549:
! 550: Installing GNU CC on the 3b1 is difficult if you do not already have
! 551: GNU CC running, due to bugs in the installed C compiler. However,
! 552: the following procedure might work. We are unable to test it.
! 553:
! 554: 1. Comment out the `#include "config.h"' line on line 37 of
! 555: `cccp.c' and do `make cpp'. This makes a preliminary version of
! 556: GNU cpp.
1.1.1.2 root 557:
1.1.1.3 ! root 558: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
! 559: file name.
1.1.1.2 root 560:
1.1.1.3 ! root 561: 3. Undo your change in `cccp.c', or reinstall the original version,
! 562: and do `make cpp' again.
! 563:
! 564: 4. Copy this final version of GNU cpp into `/lib/cpp'.
! 565:
! 566: 5. Replace every occurrence of `obstack_free' in `tree.c' with
! 567: `_obstack_free'.
! 568:
! 569: 6. Run `make' to get the first-stage GNU CC.
! 570:
! 571: 7. Reinstall the original version of `/lib/cpp'.
! 572:
! 573: 8. Now you can compile GNU CC with itself and install it in the
! 574: normal fashion.
! 575:
! 576: If you have installed an earlier version of GCC, you can compile the
! 577: newer version with that. However, you will run into trouble
! 578: compiling `gnulib', since that is normally compiled with CC. To
! 579: solve the problem, uncomment this line in `Makefile':
! 580:
! 581: CCLIBFLAGS = -B/usr/local/lib/gcc- -tp -Wp,-traditional
1.1.1.2 root 582:
583:
584:
1.1.1.3 ! root 585: File: gcc.info, Node: VMS Install, Next: HPUX Install, Prev: 3B1 Install, Up: Installation
1.1.1.2 root 586:
1.1.1.3 ! root 587: Installing GNU CC on VMS
! 588: ========================
1.1.1.2 root 589:
1.1.1.3 ! root 590: The VMS version of GNU CC is distributed in a backup saveset
! 591: containing both source code and precompiled binaries.
1.1.1.2 root 592:
1.1.1.3 ! root 593: To install the `gcc' command so you can use the compiler easily, in
! 594: the same manner as you use the VMS C compiler, you must install the
! 595: VMS CLD file for GNU CC as follows:
1.1.1.2 root 596:
1.1.1.3 ! root 597: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
! 598: point to the directories where the GNU CC executables
! 599: (`gcc-cpp', `gcc-cc1', etc.) and the C include files are kept.
! 600: This should be done with the commands:
1.1.1.2 root 601:
1.1.1.3 ! root 602: $ assign /super /system disk:[gcc.] gnu_cc
! 603: $ assign /super /system disk:[gcc.include.] gnu_cc_include
! 604:
! 605: with the appropriate disk and directory names. These commands
! 606: can be placed in your system startup file so they will be
! 607: executed whenever the machine is rebooted. You may, if you
! 608: choose, do this via the `GCC_INSTALL.COM' script in the `[GCC]'
! 609: directory.
! 610:
! 611: 2. Install the `GCC' command with the command line:
! 612:
! 613: $ set command /table=sys$library:dcltables gnu_cc:[000000]gcc
! 614:
! 615: 3. To install the help file, do the following:
! 616:
! 617: $ lib/help sys$library:helplib.hlb gcc.hlp
! 618:
! 619: Now you can invoke the compiler with a command like `gcc
! 620: /verbose file.c', which is equivalent to the command `gcc -v -c
! 621: file.c' in Unix.
! 622:
! 623: We try to put corresponding binaries and sources on the VMS
! 624: distribution tape. But sometimes the binaries will be from an older
! 625: version that the sources, because we don't always have time to update
! 626: them. (Use the `/verbose' option to determine the version number of
! 627: the binaries and compare it with the source file `version.c' to tell
! 628: whether this is so.) In this case, you should use the binaries you
! 629: get to recompile the sources. If you must recompile, here is how:
! 630:
! 631: 1. Copy the file `tm-vms.h' to `tm.h', `xm-vms.h' to `config.h',
! 632: `vax.md' to `md.' and `out-vax.c' to `aux-output.c'. The files
! 633: to be copied are found in the subdirectory named `config'; they
! 634: should be copied to the main directory of GNU CC.
! 635:
! 636: 2. Setup the logical names and command tables as defined above. In
! 637: addition, define the vms logical name `GNU_BISON' to point at
! 638: the to the directories where the Bison executable is kept. This
! 639: should be done with the command:
! 640:
! 641: $ assign /super /system disk:[bison.] gnu_bison
! 642:
! 643: You may, if you choose, use the `INSTALL_BISON.COM' script in
! 644: the `[BISON]' directory.
! 645:
! 646: 3. Install the `BISON' command with the command line:
! 647:
! 648: $ set command /table=sys$library:dcltables gnu_bison:[000000]bison
! 649:
! 650: 4. Type `@make' to do recompile everything.
! 651:
! 652: If you are compiling with a version of GNU CC older than 1.33,
! 653: specify `/DEFINE=("inline=")' as an option in all the
! 654: compilations. This requires editing all the `gcc' commands in
! 655: `make-cc1.com'. (The older versions had problems supporting
! 656: `inline'.) Once you have a working 1.33 or newer GNU CC, you
! 657: can change this file back.
! 658:
! 659: There is a known problem on VMS: `const' global variables don't work
! 660: compatibly with the VMS C compiler; we don't know a way to get them
! 661: to the linker properly.
! 662:
! 663: Note that GNU CC on VMS does not generate debugging information to
! 664: describe the program's symbols. It is not straightforward to
! 665: implement this, and we have no time to spend on it, but we might
! 666: consent to install a very modular implementation if you write it.
! 667: You will probably have to modify GAS as well as GNU CC.
1.1.1.2 root 668:
669:
670:
1.1.1.3 ! root 671: File: gcc.info, Node: HPUX Install, Prev: VMS Install, Up: Installation
1.1.1.2 root 672:
1.1.1.3 ! root 673: Installing GNU CC on HPUX
! 674: =========================
! 675:
! 676: To install GNU CC on HPUX, you must start by editing the file
! 677: `Makefile'. Search for the string `HPUX' to find comments saying
! 678: what to change. You need to change some variable definitions and (if
! 679: you are using GAS) some lines in the rule for the target `gnulib'.
1.1.1.2 root 680:
1.1.1.3 ! root 681: To compile with the HPUX C compiler, you must specify get the file
! 682: `alloca.c' from GNU Emacs. Then, when you run `make', use this
! 683: argument:
1.1.1.2 root 684:
1.1.1.3 ! root 685: make ALLOCA=alloca.o
! 686:
! 687: When recompiling GNU CC with itself, do not define `ALLOCA'.
! 688: Instead, an `-I' option needs to be added to `CFLAGS' as follows:
! 689:
! 690: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -I../binutils/hp-include"
! 691:
! 692:
! 693:
! 694: File: gcc.info, Node: Trouble, Next: Incompatibilities, Prev: Installation, Up: Top
1.1.1.2 root 695:
1.1.1.3 ! root 696: Known Causes of Trouble with GNU CC.
! 697: ************************************
1.1.1.2 root 698:
1.1.1.3 ! root 699: Here are some of the things that have caused trouble for people
! 700: installing or using GNU CC.
1.1.1.2 root 701:
1.1.1.3 ! root 702: * On certain systems, defining certain environment variables such
! 703: as `CC' can interfere with the functioning of `make'.
! 704:
! 705: * Cross compilation can run into trouble for certain machines
! 706: because some target machines' assemblers require floating point
! 707: numbers to be written as *integer* constants in certain contexts.
! 708:
! 709: The compiler writes these integer constants by examining the
! 710: floating point value as an integer and printing that integer,
! 711: because this is simple to write and independent of the details
! 712: of the floating point representation. But this does not work if
! 713: the compiler is running on a different machine with an
! 714: incompatible floating point format, or even a different
! 715: byte-ordering.
! 716:
! 717: In addition, correct constant folding of floating point values
! 718: requires representing them in the target machine's format. (The
! 719: C standard does not quite require this, but in practice it is
! 720: the only way to win.)
! 721:
! 722: It is now possible to overcome these problems by defining macros
! 723: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount
! 724: of work for each target machine. *Note Cross-compilation::.
! 725:
! 726: * DBX rejects some files produced by GNU CC, though it accepts
! 727: similar constructs in output from PCC. Until someone can supply
! 728: a coherent description of what is valid DBX input and what is
! 729: not, there is nothing I can do about these problems. You are on
! 730: your own.
1.1.1.2 root 731:
1.1.1.3 ! root 732: * Users often think it is a bug when GNU CC reports an error for
! 733: code like this:
! 734:
! 735: int foo (short);
! 736:
! 737: int foo (x)
! 738: short x;
! 739: {...}
! 740:
! 741: The error message is correct: this code really is erroneous,
! 742: because the old-style non-prototype definition passes subword
! 743: integers in their promoted types. In other words, the argument
! 744: is really an `int', not a `short'. The correct prototype is this:
! 745:
! 746: int foo (int);
! 747:
! 748: * Users often think it is a bug when GNU CC reports an error for
! 749: code like this:
! 750:
! 751: int foo (struct mumble *);
1.1.1.2 root 752:
1.1.1.3 ! root 753: struct mumble { ... };
! 754:
! 755: int foo (struct mumble *x)
1.1.1.2 root 756: { ... }
757:
1.1.1.3 ! root 758: This code really is erroneous, because the scope of `struct
! 759: mumble' the prototype is limited to the argument list containing
! 760: it. It does not refer to the `struct mumble' defined with file
! 761: scope immediately below--they are two unrelated types with
! 762: similar names in different scopes.
! 763:
! 764: But in the definition of `foo', the file-scope type is used
! 765: because that is available to be inherited. Thus, the definition
! 766: and the prototype do not match, and you get an error.
! 767:
! 768: This behavior may seem silly, but it's what the ANSI standard
! 769: specifies. It is easy enough for you to make your code work by
! 770: moving the definition of `struct mumble' above the prototype. I
! 771: don't think it's worth being incompatible for.
! 772:
! 773:
! 774:
! 775: File: gcc.info, Node: Incompatibilities, Next: Extensions, Prev: Trouble, Up: Top
! 776:
! 777: Incompatibilities of GNU CC
! 778: ***************************
! 779:
! 780: There are several noteworthy incompatibilities between GNU C and most
! 781: existing (non-ANSI) versions of C. The `-traditional' option
! 782: eliminates most of these incompatibilities, *but not all*, by telling
! 783: GNU C to behave like older C compilers.
! 784:
! 785: * GNU CC normally makes string constants read-only. If several
! 786: identical-looking string constants are used, GNU CC stores only
! 787: one copy of the string.
! 788:
! 789: One consequence is that you cannot call `mktemp' with a string
! 790: constant argument. The function `mktemp' always alters the
! 791: string its argument points to.
! 792:
! 793: Another consequence is that `sscanf' does not work on some
! 794: systems when passed a string constant as its format control
! 795: string. This is because `sscanf' incorrectly tries to write
! 796: into the string constant. Likewise `fscanf' and `scanf'.
! 797:
! 798: The best solution to these problems is to change the program to
! 799: use `char'-array variables with initialization strings for these
! 800: purposes instead of string constants. But if this is not
! 801: possible, you can use the `-fwritable-strings' flag, which
! 802: directs GNU CC to handle string constants the same way most C
! 803: compilers do. `-traditional' also has this effect, among others.
! 804:
! 805: * GNU CC does not substitute macro arguments when they appear
! 806: inside of string constants. For example, the following macro in
! 807: GNU CC
! 808:
! 809: #define foo(a) "a"
! 810:
! 811: will produce output `"a"' regardless of what the argument A is.
! 812:
! 813: The `-traditional' option directs GNU CC to handle such cases
! 814: (among others) in the old-fashioned (non-ANSI) fashion.
! 815:
! 816: * When you use `setjmp' and `longjmp', the only automatic
! 817: variables guaranteed to remain valid are those declared
! 818: `volatile'. This is a consequence of automatic register
! 819: allocation. Consider this function:
! 820:
! 821: jmp_buf j;
! 822:
! 823: foo ()
! 824: {
! 825: int a, b;
! 826:
! 827: a = fun1 ();
! 828: if (setjmp (j))
! 829: return a;
! 830:
! 831: a = fun2 ();
! 832: /* `longjmp (j)' may be occur in `fun3'. */
! 833: return a + fun3 ();
! 834: }
! 835:
! 836: Here `a' may or may not be restored to its first value when the
! 837: `longjmp' occurs. If `a' is allocated in a register, then its
! 838: first value is restored; otherwise, it keeps the last value
! 839: stored in it.
! 840:
! 841: If you use the `-W' option with the `-O' option, you will get a
! 842: warning when GNU CC thinks such a problem might be possible.
! 843:
! 844: The `-traditional' option directs GNU C to put variables in the
! 845: stack by default, rather than in registers, in functions that
! 846: call `setjmp'. This results in the behavior found in
! 847: traditional C compilers.
! 848:
! 849: * Declarations of external variables and functions within a block
! 850: apply only to the block containing the declaration. In other
! 851: words, they have the same scope as any other declaration in the
! 852: same place.
! 853:
! 854: In some other C compilers, a `extern' declaration affects all
! 855: the rest of the file even if it happens within a block.
! 856:
! 857: The `-traditional' option directs GNU C to treat all `extern'
! 858: declarations as global, like traditional compilers.
! 859:
! 860: * In traditional C, you can combine `long', etc., with a typedef
! 861: name, as shown here:
! 862:
! 863: typedef int foo;
! 864: typedef long foo bar;
! 865:
! 866: In ANSI C, this is not allowed: `long' and other type modifiers
! 867: require an explicit `int'. Because this criterion is expressed
! 868: by Bison grammar rules rather than C code, the `-traditional'
! 869: flag cannot alter it.
! 870:
! 871: * PCC allows typedef names to be used as function parameters. The
! 872: difficulty described immediately above applies here too.
! 873:
! 874: * PCC allows whitespace in the middle of compound assignment
! 875: operators such as `+='. GNU CC, following the ANSI standard,
! 876: does not allow this. The difficulty described immediately above
! 877: applies here too.
! 878:
! 879: * GNU CC will flag unterminated character constants inside of
! 880: preprocessor conditionals that fail. Some programs have English
! 881: comments enclosed in conditionals that are guaranteed to fail;
! 882: if these comments contain apostrophes, GNU CC will probably
! 883: report an error. For example, this code would produce an error:
! 884:
! 885: #if 0
! 886: You can't expect this to work.
! 887: #endif
! 888:
! 889: The best solution to such a problem is to put the text into an
! 890: actual C comment delimited by `/*...*/'. However,
! 891: `-traditional' suppresses these error messages.
! 892:
! 893: * When compiling functions that return `float', PCC converts it to
! 894: a double. GNU CC actually returns a `float'. If you are
! 895: concerned with PCC compatibility, you should declare your
! 896: functions to return `double'; you might as well say what you mean.
! 897:
! 898: * When compiling functions that return structures or unions, GNU
! 899: CC output code normally uses a method different from that used
! 900: on most versions of Unix. As a result, code compiled with GNU
! 901: CC cannot call a structure-returning function compiled with PCC,
! 902: and vice versa.
! 903:
! 904: The method used by GNU CC is as follows: a structure or union
! 905: which is 1, 2, 4 or 8 bytes long is returned like a scalar. A
! 906: structure or union with any other size is stored into an address
! 907: supplied by the caller in a special, fixed register.
! 908:
! 909: PCC usually handles all sizes of structures and unions by
! 910: returning the address of a block of static storage containing
! 911: the value. This method is not used in GNU CC because it is
! 912: slower and nonreentrant.
! 913:
! 914: You can tell GNU CC to use the PCC convention with the option
! 915: `-fpcc-struct-return'.
! 916:
! 917: * On the Sparc, GNU CC uses an incompatible calling convention for
! 918: structures. It passes them by including their contents in the
! 919: argument list, whereas the standard compiler passes them
! 920: effectively by reference.
! 921:
! 922: This really ought to be fixed, but such calling conventions are
! 923: not yet supported in GNU CC, so it isn't straightforward to fix
! 924: it.
1.1.1.2 root 925:
1.1.1.3 ! root 926: The convention for structure returning is also incompatible, and
! 927: `-fpcc-struct-return' does not help.
1.1.1.2 root 928:
929:
930:
1.1.1.3 ! root 931: File: gcc.info, Node: Extensions, Next: Bugs, Prev: Incompatibilities, Up: Top
1.1.1.2 root 932:
1.1.1.3 ! root 933: GNU Extensions to the C Language
! 934: ********************************
1.1.1.2 root 935:
1.1.1.3 ! root 936: GNU C provides several language features not found in ANSI standard C.
! 937: (The `-pedantic' option directs GNU CC to print a warning message if
! 938: any of these features is used.) To test for the availability of
! 939: these features in conditional compilation, check for a predefined
! 940: macro `__GNUC__', which is always defined under GNU CC.
1.1.1.2 root 941:
1.1.1.3 ! root 942: * Menu:
1.1.1.2 root 943:
1.1.1.3 ! root 944: * Statement Exprs:: Putting statements and declarations inside expressions.
! 945: * Naming Types:: Giving a name to the type of some expression.
! 946: * Typeof:: `typeof': referring to the type of an expression.
! 947: * Lvalues:: Using `?:', `,' and casts in lvalues.
! 948: * Conditionals:: Omitting the middle operand of a `?:' expression.
! 949: * Zero-Length:: Zero-length arrays.
! 950: * Variable-Length:: Arrays whose length is computed at run time.
! 951: * Subscripting:: Any array can be subscripted, even if not an lvalue.
! 952: * Pointer Arith:: Arithmetic on `void'-pointers and function pointers.
! 953: * Initializers:: Non-constant initializers.
! 954: * Constructors:: Constructor expressions give structures, unions
! 955: or arrays as values.
! 956: * Function Attributes:: Declaring that functions have no side effects,
! 957: or that they can never return.
! 958: * Dollar Signs:: Dollar sign is allowed in identifiers.
! 959: * Alignment:: Inquiring about the alignment of a type or variable.
! 960: * Inline:: Defining inline functions (as fast as macros).
! 961: * Extended Asm:: Assembler instructions with C expressions as operands.
! 962: (With them you can define ``built-in'' functions.)
! 963: * Asm Labels:: Specifying the assembler name to use for a C symbol.
! 964: * Explicit Reg Vars:: Defining variables residing in specified registers.
! 965: * Alternate Keywords:: `__const__', `__asm__', etc., for header files.
1.1.1.2 root 966:
1.1.1.3 ! root 967:
! 968:
! 969: File: gcc.info, Node: Statement Exprs, Next: Naming Types, Prev: Extensions, Up: Extensions
! 970:
! 971: Statements and Declarations inside of Expressions
! 972: =================================================
! 973:
! 974: A compound statement in parentheses may appear inside an expression
! 975: in GNU C. This allows you to declare variables within an expression.
! 976: For example:
! 977:
! 978: ({ int y = foo (); int z;
! 979: if (y > 0) z = y;
! 980: else z = - y;
! 981: z; })
! 982:
! 983: is a valid (though slightly more complex than necessary) expression
! 984: for the absolute value of `foo ()'.
! 985:
! 986: This feature is especially useful in making macro definitions
! 987: ``safe'' (so that they evaluate each operand exactly once). For
! 988: example, the ``maximum'' function is commonly defined as a macro in
! 989: standard C as follows:
! 990:
! 991: #define max(a,b) ((a) > (b) ? (a) : (b))
! 992:
! 993: But this definition computes either A or B twice, with bad results if
! 994: the operand has side effects. In GNU C, if you know the type of the
! 995: operands (here let's assume `int'), you can define the macro safely
! 996: as follows:
! 997:
! 998: #define maxint(a,b) \
! 999: ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
! 1000:
! 1001: Embedded statements are not allowed in constant expressions, such as
! 1002: the value of an enumeration constant, the width of a bit field, or
! 1003: the initial value of a static variable.
! 1004:
! 1005: If you don't know the type of the operand, you can still do this, but
! 1006: you must use `typeof' (*note Typeof::.) or type naming (*note Naming
! 1007: Types::.).
1.1.1.2 root 1008:
1009:
1010:
1.1.1.3 ! root 1011: File: gcc.info, Node: Naming Types, Next: Typeof, Prev: Statement Exprs, Up: Extensions
1.1.1.2 root 1012:
1.1.1.3 ! root 1013: Naming an Expression's Type
! 1014: ===========================
1.1.1.2 root 1015:
1.1.1.3 ! root 1016: You can give a name to the type of an expression using a `typedef'
! 1017: declaration with an initializer. Here is how to define NAME as a
! 1018: type name for the type of EXP:
! 1019:
! 1020: typedef NAME = EXP;
! 1021:
! 1022: This is useful in conjunction with the statements-within-expressions
! 1023: feature. Here is how the two together can be used to define a safe
! 1024: ``maximum'' macro that operates on any arithmetic type:
! 1025:
! 1026: #define max(a,b) \
! 1027: ({typedef _ta = (a), _tb = (b); \
! 1028: _ta _a = (a); _tb _b = (b); \
! 1029: _a > _b ? _a : _b; })
! 1030:
! 1031: The reason for using names that start with underscores for the local
! 1032: variables is to avoid conflicts with variable names that occur within
! 1033: the expressions that are substituted for `a' and `b'. Eventually we
! 1034: hope to design a new form of declaration syntax that allows you to
! 1035: declare variables whose scopes start only after their initializers;
! 1036: this will be a more reliable way to prevent such conflicts.
1.1.1.2 root 1037:
1038:
1039:
1.1.1.3 ! root 1040: File: gcc.info, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: Extensions
! 1041:
! 1042: Referring to a Type with `typeof'
! 1043: =================================
! 1044:
! 1045: Another way to refer to the type of an expression is with `typeof'.
! 1046: The syntax of using of this keyword looks like `sizeof', but the
! 1047: construct acts semantically like a type name defined with `typedef'.
! 1048:
! 1049: There are two ways of writing the argument to `typeof': with an
! 1050: expression or with a type. Here is an example with an expression:
! 1051:
! 1052: typeof (x[0](1))
! 1053:
! 1054: This assumes that `x' is an array of functions; the type described is
! 1055: that of the values of the functions.
! 1056:
! 1057: Here is an example with a typename as the argument:
! 1058:
! 1059: typeof (int *)
! 1060:
! 1061: Here the type described is that of pointers to `int'.
! 1062:
! 1063: If you are writing a header file that must work when included in ANSI
! 1064: C programs, write `__typeof__' instead of `typeof'. *Note Alternate
! 1065: Keywords::.
! 1066:
! 1067: A `typeof'-construct can be used anywhere a typedef name could be
! 1068: used. For example, you can use it in a declaration, in a cast, or
! 1069: inside of `sizeof' or `typeof'.
! 1070:
! 1071: * This declares `y' with the type of what `x' points to.
! 1072:
! 1073: typeof (*x) y;
1.1 root 1074:
1.1.1.3 ! root 1075: * This declares `y' as an array of such values.
1.1 root 1076:
1.1.1.3 ! root 1077: typeof (*x) y[4];
1.1 root 1078:
1.1.1.3 ! root 1079: * This declares `y' as an array of pointers to characters:
! 1080:
! 1081: typeof (typeof (char *)[4]) y;
! 1082:
! 1083: It is equivalent to the following traditional C declaration:
! 1084:
! 1085: char *y[4];
! 1086:
! 1087: To see the meaning of the declaration using `typeof', and why it
! 1088: might be a useful way to write, let's rewrite it with these
! 1089: macros:
! 1090:
! 1091: #define pointer(T) typeof(T *)
! 1092: #define array(T, N) typeof(T [N])
! 1093:
! 1094: Now the declaration can be rewritten this way:
! 1095:
! 1096: array (pointer (char), 4) y;
! 1097:
! 1098: Thus, `array (pointer (char), 4)' is the type of arrays of 4
! 1099: pointers to `char'.
! 1100:
! 1101:
! 1102:
! 1103: File: gcc.info, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: Extensions
! 1104:
! 1105: Generalized Lvalues
! 1106: ===================
! 1107:
! 1108: Compound expressions, conditional expressions and casts are allowed
! 1109: as lvalues provided their operands are lvalues. This means that you
! 1110: can take their addresses or store values into them.
! 1111:
! 1112: For example, a compound expression can be assigned, provided the last
! 1113: expression in the sequence is an lvalue. These two expressions are
! 1114: equivalent:
! 1115:
! 1116: (a, b) += 5
! 1117: a, (b += 5)
! 1118:
! 1119: Similarly, the address of the compound expression can be taken.
! 1120: These two expressions are equivalent:
! 1121:
! 1122: &(a, b)
! 1123: a, &b
! 1124:
! 1125: A conditional expression is a valid lvalue if its type is not void
! 1126: and the true and false branches are both valid lvalues. For example,
! 1127: these two expressions are equivalent:
! 1128:
! 1129: (a ? b : c) = 5
! 1130: (a ? b = 5 : (c = 5))
! 1131:
! 1132: A cast is a valid lvalue if its operand is valid. Taking the address
! 1133: of the cast is the same as taking the address without a cast, except
! 1134: for the type of the result. For example, these two expressions are
! 1135: equivalent (but the second may be valid when the type of `a' does not
! 1136: permit a cast to `int *').
! 1137:
! 1138: &(int *)a
! 1139: (int **)&a
! 1140:
! 1141: A simple assignment whose left-hand side is a cast works by
! 1142: converting the right-hand side first to the specified type, then to
! 1143: the type of the inner left-hand side expression. After this is
! 1144: stored, the value is converter back to the specified type to become
! 1145: the value of the assignment. Thus, if `a' has type `char *', the
! 1146: following two expressions are equivalent:
! 1147:
! 1148: (int)a = 5
! 1149: (int)(a = (char *)5)
! 1150:
! 1151: An assignment-with-arithmetic operation such as `+=' applied to a
! 1152: cast performs the arithmetic using the type resulting from the cast,
! 1153: and then continues as in the previous case. Therefore, these two
! 1154: expressions are equivalent:
! 1155:
! 1156: (int)a += 5
! 1157: (int)(a = (char *) ((int)a + 5))
! 1158:
! 1159:
! 1160:
! 1161: File: gcc.info, Node: Conditionals, Next: Zero-Length, Prev: Lvalues, Up: Extensions
! 1162:
! 1163: Conditional Expressions with Omitted Middle-Operands
! 1164: ====================================================
! 1165:
! 1166: The middle operand in a conditional expression may be omitted. Then
! 1167: if the first operand is nonzero, its value is the value of the
! 1168: conditional expression.
! 1169:
! 1170: Therefore, the expression
! 1171:
! 1172: x ? : y
! 1173:
! 1174: has the value of `x' if that is nonzero; otherwise, the value of `y'.
! 1175:
! 1176: This example is perfectly equivalent to
! 1177:
! 1178: x ? x : y
! 1179:
! 1180: In this simple case, the ability to omit the middle operand is not
! 1181: especially useful. When it becomes useful is when the first operand
! 1182: does, or may (if it is a macro argument), contain a side effect.
! 1183: Then repeating the operand in the middle would perform the side
! 1184: effect twice. Omitting the middle operand uses the value already
! 1185: computed without the undesirable effects of recomputing it.
! 1186:
! 1187:
! 1188:
! 1189: File: gcc.info, Node: Zero-Length, Next: Variable-Length, Prev: Conditionals, Up: Extensions
! 1190:
! 1191: Arrays of Length Zero
! 1192: =====================
! 1193:
! 1194: Zero-length arrays are allowed in GNU C. They are very useful as the
! 1195: last element of a structure which is really a header for a
! 1196: variable-length object:
! 1197:
! 1198: struct line {
! 1199: int length;
! 1200: char contents[0];
! 1201: };
! 1202:
! 1203: {
! 1204: struct line *thisline
! 1205: = (struct line *) malloc (sizeof (struct line) + this_length);
! 1206: thisline->length = this_length;
! 1207: }
! 1208:
! 1209: In standard C, you would have to give `contents' a length of 1, which
! 1210: means either you waste space or complicate the argument to `malloc'.
! 1211:
! 1212:
! 1213:
! 1214: File: gcc.info, Node: Variable-Length, Next: Subscripting, Prev: Zero-Length, Up: Extensions
! 1215:
! 1216: Arrays of Variable Length
! 1217: =========================
! 1218:
! 1219: Variable-length automatic arrays are allowed in GNU C. These arrays
! 1220: are declared like any other automatic arrays, but with a length that
! 1221: is not a constant expression. The storage is allocated at that time
! 1222: and deallocated when the brace-level is exited. For example:
! 1223:
! 1224: FILE *concat_fopen (char *s1, char *s2, char *mode)
! 1225: {
! 1226: char str[strlen (s1) + strlen (s2) + 1];
! 1227: strcpy (str, s1);
! 1228: strcat (str, s2);
! 1229: return fopen (str, mode);
! 1230: }
! 1231:
! 1232: You can also use variable-length arrays as arguments to functions:
! 1233:
! 1234: struct entry
! 1235: tester (int len, char data[len])
1.1 root 1236: {
1237: ...
1238: }
1239:
1.1.1.3 ! root 1240: The length of an array is computed on entry to the brace-level where
! 1241: the array is declared and is remembered for the scope of the array in
! 1242: case you access it with `sizeof'.
! 1243:
! 1244: Jumping or breaking out of the scope of the array name will also
! 1245: deallocate the storage. Jumping into the scope is not allowed; you
! 1246: will get an error message for it.
! 1247:
! 1248: You can use the function `alloca' to get an effect much like
! 1249: variable-length arrays. The function `alloca' is available in many
! 1250: other C implementations (but not in all). On the other hand,
! 1251: variable-length arrays are more elegant.
! 1252:
! 1253: There are other differences between these two methods. Space
! 1254: allocated with `alloca' exists until the containing *function* returns.
! 1255: The space for a variable-length array is deallocated as soon as the
! 1256: array name's scope ends. (If you use both variable-length arrays and
! 1257: `alloca' in the same function, deallocation of a variable-length
! 1258: array will also deallocate anything more recently allocated with
! 1259: `alloca'.)
1.1 root 1260:
1261:
1262:
1.1.1.3 ! root 1263: File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Variable-Length, Up: Extensions
1.1 root 1264:
1.1.1.3 ! root 1265: Non-Lvalue Arrays May Have Subscripts
! 1266: =====================================
1.1 root 1267:
1.1.1.3 ! root 1268: Subscripting is allowed on arrays that are not lvalues, even though
! 1269: the unary `&' operator is not. For example, this is valid in GNU C
! 1270: though not valid in other C dialects:
! 1271:
! 1272: struct foo {int a[4];};
! 1273:
! 1274: struct foo f();
! 1275:
! 1276: bar (int index)
! 1277: {
! 1278: return f().a[index];
! 1279: }
1.1 root 1280:
1281:
1282:
1.1.1.3 ! root 1283: File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: Extensions
1.1 root 1284:
1.1.1.3 ! root 1285: Arithmetic on `void'-Pointers and Function Pointers
! 1286: ===================================================
1.1 root 1287:
1.1.1.3 ! root 1288: In GNU C, addition and subtraction operations are supported on
! 1289: pointers to `void' and on pointers to functions. This is done by
! 1290: treating the size of a `void' or of a function as 1.
1.1 root 1291:
1.1.1.3 ! root 1292: A consequence of this is that `sizeof' is also allowed on `void' and
! 1293: on function types, and returns 1.
! 1294:
! 1295: The option `-Wpointer-arith' requests a warning if these extensions
! 1296: are used.
! 1297:
! 1298:
! 1299:
! 1300: File: gcc.info, Node: Initializers, Next: Constructors, Prev: Pointer Arith, Up: Extensions
! 1301:
! 1302: Non-Constant Initializers
! 1303: =========================
! 1304:
! 1305: The elements of an aggregate initializer for an automatic variable
! 1306: are not required to be constant expressions in GNU C. Here is an
! 1307: example of an initializer with run-time varying elements:
! 1308:
! 1309: foo (float f, float g)
! 1310: {
! 1311: float beat_freqs[2] = { f-g, f+g };
! 1312: ...
! 1313: }
! 1314:
! 1315:
! 1316:
! 1317: File: gcc.info, Node: Constructors, Next: Function Attributes, Prev: Initializers, Up: Extensions
! 1318:
! 1319: Constructor Expressions
! 1320: =======================
! 1321:
! 1322: GNU C supports constructor expressions. A constructor looks like a
! 1323: cast containing an initializer. Its value is an object of the type
! 1324: specified in the cast, containing the elements specified in the
! 1325: initializer. The type must be a structure, union or array type.
! 1326:
! 1327: Assume that `struct foo' and `structure' are declared as shown:
! 1328:
! 1329: struct foo {int a; char b[2];} structure;
! 1330:
! 1331: Here is an example of constructing a `struct foo' with a constructor:
! 1332:
! 1333: structure = ((struct foo) {x + y, 'a', 0});
! 1334:
! 1335: This is equivalent to writing the following:
! 1336:
! 1337: {
! 1338: struct foo temp = {x + y, 'a', 0};
! 1339: structure = temp;
! 1340: }
! 1341:
! 1342: You can also construct an array. If all the elements of the
! 1343: constructor are (made up of) simple constant expressions, suitable
! 1344: for use in initializers, then the constructor is an lvalue and can be
! 1345: coerced to a pointer to its first element, as shown here:
! 1346:
! 1347: char **foo = (char *[]) { "x", "y", "z" };
! 1348:
! 1349: Array constructors whose elements are not simple constants are not
! 1350: very useful, because the constructor is not an lvalue. There are
! 1351: only two valid ways to use it: to subscript it, or initialize an
! 1352: array variable with it. The former is probably slower than a
! 1353: `switch' statement, while the latter does the same thing an ordinary
! 1354: C initializer would do.
! 1355:
! 1356: output = ((int[]) { 2, x, 28 }) [input];
1.1 root 1357:
1358:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.