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