![[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:
1.1.1.8 ! root 500: On some machines, you will find that starts to recompile the `.c'
! 501: files, due to a bug in Make. If that happens, cancel it and try
! 502: again specifying the same values for Make variables that you used
! 503: in the last compilation; that may not prevent the spurious
! 504: recompilation, but will at least do it properly. For example:
! 505:
! 506: make CC=stage2/gcc CFLAGS="-g -O -Bstage2/" install
! 507:
! 508: The `install' target copies the files `cc1', `cpp' and `gnulib' to
! 509: files `gcc-cc1', `gcc-cpp' and `gcc-gnulib' in directory
1.1.1.7 root 510: `/usr/local/lib', which is where the compiler driver program looks
511: for them. It also copies the driver program `gcc' into the
512: directory `/usr/local/bin', so that it appears in typical
1.1.1.3 root 513: execution search paths.
514:
1.1.1.7 root 515: *Warning: there is a bug in `alloca' in the Sun library. To avoid
516: this bug, install the binaries of GNU CC that were compiled by GNU
517: CC. They use `alloca' as a built-in function and never the one in
518: the library.*
519:
520: *Warning: the GNU CPP may not work for `ioctl.h', `ttychars.h' and
521: other system header files unless the `-traditional' option is
522: used.* The bug is in the header files: at least on some machines,
523: they rely on behavior that is incompatible with ANSI C. This
524: behavior consists of substituting for macro argument names when
525: they appear inside of character constants. The `-traditional'
526: option tells GNU CC to behave the way these headers expect.
1.1.1.3 root 527:
1.1.1.7 root 528: Because of this problem, you might prefer to configure GNU CC to
529: use the system's own C preprocessor. To do so, make the file
1.1.1.3 root 530: `/usr/local/lib/gcc-cpp' a link to `/lib/cpp'.
531:
1.1.1.7 root 532: Alternatively, on Sun systems and 4.3BSD at least, you can correct
533: the include files by running the shell script `fixincludes'. This
534: installs modified, corrected copies of the files `ioctl.h',
535: `ttychars.h' and many others, in a special directory where only
536: GNU CC will normally look for them. This script will work on
537: various systems because it chooses the files by searching all the
538: system headers for the problem cases that we know about.
1.1.1.3 root 539:
1.1.1.7 root 540: Use the following command to do this:
1.1.1.4 root 541:
542: make includes
543:
1.1.1.7 root 544: If you selected a different directory for GNU CC installation when
545: you installed it, by specifying the Make variable `prefix' or
546: `libdir', specify it the same way in this command.
547:
548: Note that some systems are starting to come with ANSI C system
549: header files. On these systems, don't run `fixincludes'; it may
550: not work, and is certainly not necessary.
551:
552: *Warning:* `fixincludes' does not work on many MIPS systems,
553: because those systems come with circular symbolic links which cause
1.1.1.8 ! root 554: `ls -lR' to go into an infinite loop. The same problem may occur
! 555: on some versions of SunOS. If you encounter this problem, try
! 556: using `fixinc.new' instead opf `fixincludes'.
1.1.1.7 root 557:
558: If you cannot install the compiler's passes and run-time support in
559: `/usr/local/lib', you can alternatively use the `-B' option to specify
560: a prefix by which they may be found. The compiler concatenates the
561: prefix with the names `cpp', `cc1' and `gnulib'. Thus, you can put the
562: files in a directory `/usr/foo/gcc' and specify `-B/usr/foo/gcc/' when
563: you run GNU CC.
1.1.1.2 root 564:
1.1.1.6 root 565: Also, you can specify an alternative default directory for these
1.1.1.3 root 566: files by setting the Make variable `libdir' when you make GNU CC.
1.1.1.2 root 567:
568:
1.1.1.3 root 569: File: gcc.info, Node: Other Dir, Next: Sun Install, Prev: Installation, Up: Installation
1.1.1.2 root 570:
1.1.1.3 root 571: Compilation in a Separate Directory
572: ===================================
1.1.1.2 root 573:
1.1.1.7 root 574: If you wish to build the object files and executables in a directory
575: other than the one containing the source files, here is what you must
576: do differently:
1.1.1.2 root 577:
1.1.1.3 root 578: 1. Go to that directory before running `config.gcc':
1.1.1.2 root 579:
1.1.1.3 root 580: mkdir gcc-sun3
581: cd gcc-sun3
1.1.1.2 root 582:
1.1.1.7 root 583: On systems that do not support symbolic links, this directory must
584: be on the same file system as the source code directory.
1.1.1.2 root 585:
1.1.1.3 root 586: 2. Specify where to find `config.gcc' when you run it:
1.1.1.2 root 587:
1.1.1.3 root 588: ../gcc-1.36/config.gcc ...
589:
590: 3. Specify where to find the sources, as an argument to `config.gcc':
591:
592: ../gcc-1.36/config.gcc -srcdir=../gcc-1.36 sun3
593:
1.1.1.7 root 594: The `-srcdir=DIR' option is not needed when the source directory
595: is the parent of the current directory, because `config.gcc'
596: detects that case automatically.
597:
598: Now, you can run `make' in that directory. You need not repeat the
599: configuration steps shown above, when ordinary source files change. You
600: must, however, run `config.gcc' again when the configuration files
601: change, if your system does not support symbolic links.
1.1.1.2 root 602:
603:
1.1.1.3 root 604: File: gcc.info, Node: Sun Install, Next: 3b1 Install, Prev: Other Dir, Up: Installation
1.1.1.2 root 605:
1.1.1.3 root 606: Installing GNU CC on the Sun
607: ============================
1.1.1.2 root 608:
1.1.1.6 root 609: Make sure the environment variable `FLOAT_OPTION' is not set when
610: you compile `gnulib'. If this option were set to `f68881' when
1.1.1.7 root 611: `gnulib' is compiled, the resulting code would demand to be linked with
612: a special startup file and would not link properly without special
613: pains.
1.1.1.3 root 614:
1.1.1.6 root 615: There is a bug in `alloca' in certain versions of the Sun library.
1.1.1.7 root 616: To avoid this bug, install the binaries of GNU CC that were compiled by
617: GNU CC. They use `alloca' as a built-in function and never the one in
618: the library.
619:
620: Some versions of the Sun compiler crash when compiling GNU CC, with a
621: segmentation fault in cpp. This can sometimes be due to the bulk of
622: data in the environment variables. You may be able to avoid it by using
623: the following command to compile GNU CC with Sun CC:
1.1.1.2 root 624:
1.1.1.3 root 625: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
1.1.1.2 root 626:
1.1.1.6 root 627: Another problem that often happens on Suns is that you get a crash
1.1.1.5 root 628: when building stage 2, when `genflags' is run.
629:
1.1.1.6 root 630: One reason for such as crash is if you configured GNU CC for the
1.1.1.5 root 631: wrong version of SunOS. Starting with version 1.38, configurations
632: `sun3' and `sun4' are for SunOS 4, so this problem should no longer
633: happen.
634:
1.1.1.7 root 635: Another cause of the same symptom is having installed the GNU linker
636: with an earlier version of SunOS. The version that worked before
637: stopped working due to a change in the format of executables in SunOS
638: 4.1. Many sites have installed the GNU linker as
1.1.1.5 root 639: `/usr/local/lib/gcc-ld', often as part of installing GNU C++. So if
640: you get such crashes and you have used the proper configuration, try
641: deleting `/usr/local/lib/gcc-ld'.
642:
1.1.1.7 root 643: The current version of the GNU linker, found in the current binutils
644: release, does work with SunOS 4.1.
1.1.1.2 root 645:
646:
1.1.1.4 root 647: File: gcc.info, Node: 3b1 Install, Next: SCO Install, Prev: Sun Install, Up: Installation
1.1.1.3 root 648:
649: Installing GNU CC on the 3b1
650: ============================
651:
1.1.1.7 root 652: Installing GNU CC on the 3b1 is difficult if you do not already have
653: GNU CC running, due to bugs in the installed C compiler. However, the
654: following procedure might work. We are unable to test it.
655:
656: 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c'
657: and do `make cpp'. This makes a preliminary version of GNU cpp.
1.1.1.2 root 658:
1.1.1.3 root 659: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
660: file name.
1.1.1.2 root 661:
1.1.1.3 root 662: 3. Undo your change in `cccp.c', or reinstall the original version,
663: and do `make cpp' again.
664:
665: 4. Copy this final version of GNU cpp into `/lib/cpp'.
666:
667: 5. Replace every occurrence of `obstack_free' in `tree.c' with
668: `_obstack_free'.
669:
670: 6. Run `make' to get the first-stage GNU CC.
671:
672: 7. Reinstall the original version of `/lib/cpp'.
673:
1.1.1.7 root 674: 8. Now you can compile GNU CC with itself and install it in the normal
675: fashion.
1.1.1.3 root 676:
1.1.1.7 root 677: If you have installed an earlier version of GCC, you can compile the
678: newer version with that. However, you will run into trouble compiling
679: `gnulib', since that is normally compiled with CC. To solve the
680: problem, uncomment this line in `Makefile':
1.1.1.3 root 681:
682: CCLIBFLAGS = -B/usr/local/lib/gcc- -tp -Wp,-traditional
1.1.1.2 root 683:
684:
1.1.1.4 root 685: File: gcc.info, Node: SCO Install, Next: VMS Install, Prev: 3B1 Install, Up: Installation
686:
687: Installing GNU CC on SCO System V 3.2
688: =====================================
689:
1.1.1.7 root 690: The compiler that comes with this system does not work properly with
691: `-O'. Therefore, you should redefine the Make variable `CCLIBFLAGS'
692: not to use `-O'.
693:
694: You should also edit `Makefile' to enable the lines that set `CLIB'
695: to `-lPW', and the ones specifically labeled as being for SCO, that set
696: `RANLIB', and that set `CC' and `OLDCC' to `rcc -Di386 -DM_UNIX
697: -DM_I386 -DM_SYSV -DM_COFF'.
1.1.1.5 root 698:
1.1.1.6 root 699: Also, edit the definition of `USER_H' to remove the file `limits.h'.
1.1.1.5 root 700:
1.1.1.6 root 701: Then you can run `config.gcc i386-sco' and finish building GNU CC
1.1.1.5 root 702: normally.
703:
1.1.1.7 root 704: Note that the function `memmove' is broken in 3.2v2; it clobbers
705: register `%ebx'. See the file `sco-memmove.s'.
706:
707: The same recipe should work on ESIX, but use `config.gcc i386-esix'
708: instead.
1.1.1.4 root 709:
710:
711: File: gcc.info, Node: VMS Install, Next: HPUX Install, Prev: SCO Install, Up: Installation
1.1.1.2 root 712:
1.1.1.3 root 713: Installing GNU CC on VMS
714: ========================
1.1.1.2 root 715:
1.1.1.6 root 716: The VMS version of GNU CC is distributed in a backup saveset
1.1.1.3 root 717: containing both source code and precompiled binaries.
1.1.1.2 root 718:
1.1.1.7 root 719: To install the `gcc' command so you can use the compiler easily, in
720: the same manner as you use the VMS C compiler, you must install the VMS
721: CLD file for GNU CC as follows:
1.1.1.2 root 722:
1.1.1.3 root 723: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
1.1.1.7 root 724: point to the directories where the GNU CC executables (`gcc-cpp',
725: `gcc-cc1', etc.) and the C include files are kept. This should be
726: done with the commands:
1.1.1.2 root 727:
1.1.1.3 root 728: $ assign /super /system disk:[gcc.] gnu_cc
729: $ assign /super /system disk:[gcc.include.] gnu_cc_include
730:
1.1.1.7 root 731: with the appropriate disk and directory names. These commands can
732: be placed in your system startup file so they will be executed
733: whenever the machine is rebooted. You may, if you choose, do this
734: via the `GCC_INSTALL.COM' script in the `[GCC]' directory.
1.1.1.3 root 735:
736: 2. Install the `GCC' command with the command line:
737:
738: $ set command /table=sys$library:dcltables gnu_cc:[000000]gcc
739:
740: 3. To install the help file, do the following:
741:
742: $ lib/help sys$library:helplib.hlb gcc.hlp
743:
1.1.1.7 root 744: Now you can invoke the compiler with a command like `gcc /verbose
745: file.c', which is equivalent to the command `gcc -v -c file.c' in
746: Unix.
1.1.1.3 root 747:
1.1.1.6 root 748: We try to put corresponding binaries and sources on the VMS
1.1.1.3 root 749: distribution tape. But sometimes the binaries will be from an older
750: version that the sources, because we don't always have time to update
751: them. (Use the `/verbose' option to determine the version number of
752: the binaries and compare it with the source file `version.c' to tell
1.1.1.7 root 753: whether this is so.) In this case, you should use the binaries you get
754: to recompile the sources. If you must recompile, here is how:
1.1.1.3 root 755:
756: 1. Copy the file `tm-vms.h' to `tm.h', `xm-vms.h' to `config.h',
1.1.1.7 root 757: `vax.md' to `md.' and `out-vax.c' to `aux-output.c'. The files to
758: be copied are found in the subdirectory named `config'; they
1.1.1.3 root 759: should be copied to the main directory of GNU CC.
760:
761: 2. Setup the logical names and command tables as defined above. In
1.1.1.7 root 762: addition, define the vms logical name `GNU_BISON' to point at the
763: to the directories where the Bison executable is kept. This
1.1.1.3 root 764: should be done with the command:
765:
766: $ assign /super /system disk:[bison.] gnu_bison
767:
1.1.1.7 root 768: You may, if you choose, use the `INSTALL_BISON.COM' script in the
769: `[BISON]' directory.
1.1.1.3 root 770:
771: 3. Install the `BISON' command with the command line:
772:
773: $ set command /table=sys$library:dcltables gnu_bison:[000000]bison
774:
775: 4. Type `@make' to do recompile everything.
776:
1.1.1.7 root 777: If you are compiling with a version of GNU CC older than 1.33,
778: specify `/DEFINE=("inline=")' as an option in all the
1.1.1.3 root 779: compilations. This requires editing all the `gcc' commands in
1.1.1.7 root 780: `make-cc1.com'. (The older versions had problems supporting
781: `inline'.) Once you have a working 1.33 or newer GNU CC, you can
782: change this file back.
783:
784: Due to the differences between the filesystems of Unix and VMS, the
785: preprocessor attempts to translate the names of include files into
786: something that VMS will understand. The basic strategy is to prepend a
787: prefix to the specification of the include file, convert the whole
788: filename to a VMS filename, and then try to open the file. The
789: preprocessor tries various prefixes until one of them succeeds.
1.1.1.6 root 790:
791: The first prefix is the `GNU_CC_INCLUDE:' logical name: this is
1.1.1.7 root 792: where GNU_C header files are traditionally stored. If a header file is
793: not found there, `SYS$SYSROOT:[SYSLIB.]' is tried next. If the
1.1.1.6 root 794: preprocessor is still unable to locate the file, it then assumes that
795: the include file specification is a valid VMS filename all by itself,
1.1.1.7 root 796: and it uses this filename to attempt to open the include file. If none
797: of these strategies succeeds, the preprocessor reports an error.
1.1.1.6 root 798:
1.1.1.7 root 799: If you wish to store header files in non-standard locations, then you
800: can assign the logical `GNU_CC_INCLUDE' to be a search list, where each
801: element of the list is suitable for use with a rooted logical.
1.1.1.6 root 802:
803: With this version of GNU CC, `const' global variables now work
1.1.1.4 root 804: properly. Unless, however, the `const' modifier is also specified in
805: every external declaration of the variable in all of the source files
1.1.1.7 root 806: that use that variable, the linker will issue warnings about conflicting
807: attributes for the variable, since the linker does not know if the
808: variable should be read-only. The program will still work, but the
809: variable will be placed in writable storage.
1.1.1.4 root 810:
1.1.1.6 root 811: Due to an assembler bug, offsets to static constants are sometimes
1.1.1.7 root 812: incorrectly evaluated. This bug is present in GAS 1.38.1, and should be
813: fixed in the next version.
1.1.1.6 root 814:
815: Under previous versions of GNU CC, the generated code would
1.1.1.7 root 816: occasionally give strange results when linked to the sharable `VAXCRTL'
817: library. Now this should work.
1.1.1.4 root 818:
1.1.1.7 root 819: Even with this version, however, GNU CC itself should not be linked
820: to the sharable `VAXCRTL'. The `qsort' routine supplied with `VAXCRTL'
821: has a bug which can cause a compiler crash.
1.1.1.6 root 822:
823: Similarly, the preprocessor should not be linked to the sharable
824: `VAXCRTL'. The `strncat' routine supplied with `VAXCRTL' has a bug
825: which can cause the preprocessor to go into an infinite loop.
826:
1.1.1.7 root 827: It should be pointed out that if you attempt to link to the sharable
828: `VAXCRTL', the VMS linker will strongly resist any effort to force it
829: to use the `qsort' and `strncat' routines from `gcclib'. Until the
830: bugs in `VAXCRTL' have been fixed, linking any of the compiler
831: components to the sharable VAXCRTL is not recommended. (These routines
832: can be bypassed by placing duplicate copies of `qsort' and `strncat' in
833: `gcclib' under different names, and patching the compiler sources to
834: use these routines). Both of the bugs in `VAXCRTL' are still present
835: in VMS version 5.4-1, which is the most recent version as of this
836: writing.
1.1.1.6 root 837:
838: The executables that are generated by `make-cc1.com' and
839: `make-cccp.com' use the non-shared version of `VAXCRTL' (and thus use
840: the `qsort' and `strncat' routines from `gcclib.olb').
1.1.1.4 root 841:
1.1.1.6 root 842: Note that GNU CC on VMS now generates debugging information to
1.1.1.4 root 843: describe the programs symbols to the VMS debugger. However, you need
844: version 1.37 or later of GAS in order to output them properly in the
845: object file.
1.1.1.2 root 846:
1.1.1.6 root 847: The VMS linker does not distinguish between upper and lower case
848: letters in function and variable names. However, usual practice in C
1.1.1.7 root 849: is to distinguish case. Normally GNU C (by means of the assembler GAS)
850: implements usual C behavior by augmenting each name that is not all
851: lower-case. A name is augmented by truncating it to at most 23
852: characters and then adding more characters at the end which encode the
853: case pattern the rest.
1.1.1.6 root 854:
855: Name augmentation yields bad results for programs that use
856: precompiled libraries (such as Xlib) which were generated by another
857: compiler. Use the compiler option `/NOCASE_HACK' to inhibits
858: augmentation; it makes external C functions and variables
859: case-independent as is usual on VMS. Alternatively, you could write
860: all references to the functions and variables in such libraries using
861: lower case; this will work on VMS, but is not portable to other
1.1.1.7 root 862: systems. In cases where you need to selectively inhibit augmentation,
863: you can define a macro for each mixed case symbol for which you wish to
864: inhibit augmentation, where the macro expands into the lower case
865: equivalent of the name.
1.1.1.2 root 866:
867:
1.1.1.6 root 868: File: gcc.info, Node: HPUX Install, Next: Tower Install, Prev: VMS Install, Up: Installation
1.1.1.2 root 869:
1.1.1.3 root 870: Installing GNU CC on HPUX
871: =========================
872:
1.1.1.6 root 873: To install GNU CC on HPUX, you must start by editing the file
1.1.1.7 root 874: `Makefile'. Search for the string `HPUX' to find comments saying what
875: to change. You need to change some variable definitions and (if you
876: are using GAS) some lines in the rule for the target `gnulib'.
1.1.1.2 root 877:
1.1.1.6 root 878: To avoid errors when linking programs with `-g', create an empty
1.1.1.4 root 879: library named `libg.a'. An easy way to do this is:
880:
881: ar rc /usr/local/lib/libg.a
882:
1.1.1.6 root 883: To compile with the HPUX C compiler, you must specify get the file
1.1.1.3 root 884: `alloca.c' from GNU Emacs. Then, when you run `make', use this
885: argument:
1.1.1.2 root 886:
1.1.1.3 root 887: make ALLOCA=alloca.o
888:
1.1.1.7 root 889: When recompiling GNU CC with itself, do not define `ALLOCA'.
1.1.1.3 root 890: Instead, an `-I' option needs to be added to `CFLAGS' as follows:
891:
892: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -I../binutils/hp-include"
893:
1.1.1.4 root 894:
1.1.1.6 root 895: File: gcc.info, Node: Tower Install, Prev: HPUX Install, Up: Installation
1.1.1.5 root 896:
897: Installing GNU CC on an NCR Tower
898: =================================
899:
1.1.1.6 root 900: On an NCR Tower model 4x0 or 6x0, you may have trouble because the
1.1.1.5 root 901: default maximum virtual address size of a process is just 1 Mb. Most
902: often you will find this problem while compiling GNU CC with itself.
903:
1.1.1.7 root 904: The only way to solve the problem is to reconfigure the kernel. Add
905: a line such as this to the configuration file:
1.1.1.5 root 906:
907: MAXUMEM = 4096
908:
909: and then relink the kernel and reboot the machine.
910:
911:
1.1.1.4 root 912: File: gcc.info, Node: Trouble, Next: Service, Prev: Installation, Up: Top
913:
914: Known Causes of Trouble with GNU CC
915: ***********************************
1.1.1.2 root 916:
1.1.1.6 root 917: Here are some of the things that have caused trouble for people
1.1.1.3 root 918: installing or using GNU CC.
1.1.1.2 root 919:
1.1.1.7 root 920: * On certain systems, defining certain environment variables such as
921: `CC' can interfere with the functioning of `make'.
1.1.1.3 root 922:
1.1.1.7 root 923: * Cross compilation can run into trouble for certain machines because
924: some target machines' assemblers require floating point numbers to
925: be written as *integer* constants in certain contexts.
1.1.1.3 root 926:
927: The compiler writes these integer constants by examining the
928: floating point value as an integer and printing that integer,
1.1.1.7 root 929: because this is simple to write and independent of the details of
930: the floating point representation. But this does not work if the
931: compiler is running on a different machine with an incompatible
932: floating point format, or even a different byte-ordering.
1.1.1.3 root 933:
934: In addition, correct constant folding of floating point values
1.1.1.7 root 935: requires representing them in the target machine's format. (The C
936: standard does not quite require this, but in practice it is the
937: only way to win.)
1.1.1.3 root 938:
939: It is now possible to overcome these problems by defining macros
1.1.1.7 root 940: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of
941: work for each target machine. *Note Cross-compilation::.
1.1.1.3 root 942:
1.1.1.7 root 943: * Users often think it is a bug when GNU CC reports an error for code
944: like this:
1.1.1.3 root 945:
946: int foo (short);
947:
948: int foo (x)
949: short x;
950: {...}
951:
952: The error message is correct: this code really is erroneous,
953: because the old-style non-prototype definition passes subword
1.1.1.7 root 954: integers in their promoted types. In other words, the argument is
955: really an `int', not a `short'. The correct prototype is this:
1.1.1.3 root 956:
957: int foo (int);
958:
1.1.1.7 root 959: * Users often think it is a bug when GNU CC reports an error for code
960: like this:
1.1.1.3 root 961:
962: int foo (struct mumble *);
1.1.1.2 root 963:
1.1.1.3 root 964: struct mumble { ... };
965:
966: int foo (struct mumble *x)
1.1.1.2 root 967: { ... }
968:
1.1.1.3 root 969: This code really is erroneous, because the scope of `struct
970: mumble' the prototype is limited to the argument list containing
1.1.1.7 root 971: it. It does not refer to the `struct mumble' defined with file
972: scope immediately below--they are two unrelated types with similar
973: names in different scopes.
1.1.1.3 root 974:
975: But in the definition of `foo', the file-scope type is used
976: because that is available to be inherited. Thus, the definition
977: and the prototype do not match, and you get an error.
978:
979: This behavior may seem silly, but it's what the ANSI standard
980: specifies. It is easy enough for you to make your code work by
981: moving the definition of `struct mumble' above the prototype. I
982: don't think it's worth being incompatible for.
983:
1.1.1.6 root 984: Additional problems are described in *Note Incompatibilities::.
1.1.1.3 root 985:
986:
1.1.1.4 root 987: File: gcc.info, Node: Service, Next: Incompatibilities, Prev: Trouble, Up: Top
988:
989: How To Get Help with GNU CC
990: ***************************
991:
1.1.1.7 root 992: If you need help installing, using or changing GNU CC, there are two
993: ways to find it:
1.1.1.4 root 994:
995: * Send a message to a suitable network mailing list. First try
996: `[email protected]', and if that brings no response, try
1.1.1.6 root 997: `[email protected]'.
1.1.1.4 root 998:
1.1.1.7 root 999: * Look in the service directory for someone who might help you for a
1000: fee. The service directory is found in the file named `SERVICE' in
1001: the GNU CC distribution.
1.1.1.4 root 1002:
1003:
1004: File: gcc.info, Node: Incompatibilities, Next: Extensions, Prev: Service, Up: Top
1.1.1.3 root 1005:
1006: Incompatibilities of GNU CC
1007: ***************************
1008:
1.1.1.7 root 1009: There are several noteworthy incompatibilities between GNU C and most
1010: existing (non-ANSI) versions of C. The `-traditional' option
1.1.1.3 root 1011: eliminates most of these incompatibilities, *but not all*, by telling
1012: GNU C to behave like older C compilers.
1013:
1014: * GNU CC normally makes string constants read-only. If several
1.1.1.7 root 1015: identical-looking string constants are used, GNU CC stores only one
1016: copy of the string.
1.1.1.3 root 1017:
1018: One consequence is that you cannot call `mktemp' with a string
1.1.1.7 root 1019: constant argument. The function `mktemp' always alters the string
1020: its argument points to.
1021:
1022: Another consequence is that `sscanf' does not work on some systems
1023: when passed a string constant as its format control string. This
1024: is because `sscanf' incorrectly tries to write into the string
1025: constant. Likewise `fscanf' and `scanf'.
1026:
1027: The best solution to these problems is to change the program to use
1028: `char'-array variables with initialization strings for these
1029: purposes instead of string constants. But if this is not possible,
1030: you can use the `-fwritable-strings' flag, which directs GNU CC to
1031: handle string constants the same way most C compilers do.
1032: `-traditional' also has this effect, among others.
1.1.1.3 root 1033:
1.1.1.7 root 1034: * GNU CC does not substitute macro arguments when they appear inside
1035: of string constants. For example, the following macro in GNU CC
1.1.1.3 root 1036:
1037: #define foo(a) "a"
1038:
1039: will produce output `"a"' regardless of what the argument A is.
1040:
1041: The `-traditional' option directs GNU CC to handle such cases
1042: (among others) in the old-fashioned (non-ANSI) fashion.
1043:
1.1.1.7 root 1044: * When you use `setjmp' and `longjmp', the only automatic variables
1045: guaranteed to remain valid are those declared `volatile'. This is
1046: a consequence of automatic register allocation. Consider this
1047: function:
1.1.1.3 root 1048:
1049: jmp_buf j;
1050:
1051: foo ()
1052: {
1053: int a, b;
1054:
1055: a = fun1 ();
1056: if (setjmp (j))
1057: return a;
1058:
1059: a = fun2 ();
1060: /* `longjmp (j)' may be occur in `fun3'. */
1061: return a + fun3 ();
1062: }
1063:
1064: Here `a' may or may not be restored to its first value when the
1065: `longjmp' occurs. If `a' is allocated in a register, then its
1.1.1.7 root 1066: first value is restored; otherwise, it keeps the last value stored
1067: in it.
1.1.1.3 root 1068:
1069: If you use the `-W' option with the `-O' option, you will get a
1070: warning when GNU CC thinks such a problem might be possible.
1071:
1072: The `-traditional' option directs GNU C to put variables in the
1.1.1.7 root 1073: stack by default, rather than in registers, in functions that call
1074: `setjmp'. This results in the behavior found in traditional C
1075: compilers.
1.1.1.3 root 1076:
1077: * Declarations of external variables and functions within a block
1078: apply only to the block containing the declaration. In other
1079: words, they have the same scope as any other declaration in the
1080: same place.
1081:
1.1.1.7 root 1082: In some other C compilers, a `extern' declaration affects all the
1083: rest of the file even if it happens within a block.
1.1.1.3 root 1084:
1085: The `-traditional' option directs GNU C to treat all `extern'
1086: declarations as global, like traditional compilers.
1087:
1088: * In traditional C, you can combine `long', etc., with a typedef
1089: name, as shown here:
1090:
1091: typedef int foo;
1092: typedef long foo bar;
1093:
1094: In ANSI C, this is not allowed: `long' and other type modifiers
1.1.1.7 root 1095: require an explicit `int'. Because this criterion is expressed by
1096: Bison grammar rules rather than C code, the `-traditional' flag
1097: cannot alter it.
1.1.1.3 root 1098:
1099: * PCC allows typedef names to be used as function parameters. The
1100: difficulty described immediately above applies here too.
1101:
1102: * PCC allows whitespace in the middle of compound assignment
1.1.1.7 root 1103: operators such as `+='. GNU CC, following the ANSI standard, does
1104: not allow this. The difficulty described immediately above
1.1.1.3 root 1105: applies here too.
1106:
1107: * GNU CC will flag unterminated character constants inside of
1108: preprocessor conditionals that fail. Some programs have English
1.1.1.7 root 1109: comments enclosed in conditionals that are guaranteed to fail; if
1110: these comments contain apostrophes, GNU CC will probably report an
1111: error. For example, this code would produce an error:
1.1.1.3 root 1112:
1113: #if 0
1114: You can't expect this to work.
1115: #endif
1116:
1117: The best solution to such a problem is to put the text into an
1.1.1.7 root 1118: actual C comment delimited by `/*...*/'. However, `-traditional'
1119: suppresses these error messages.
1.1.1.3 root 1120:
1.1.1.7 root 1121: * When compiling functions that return `float', PCC converts it to a
1122: double. GNU CC actually returns a `float'. If you are concerned
1123: with PCC compatibility, you should declare your functions to return
1124: `double'; you might as well say what you mean.
1125:
1126: * When compiling functions that return structures or unions, GNU CC
1127: output code normally uses a method different from that used on most
1128: versions of Unix. As a result, code compiled with GNU CC cannot
1129: call a structure-returning function compiled with PCC, and vice
1130: versa.
1.1.1.3 root 1131:
1132: The method used by GNU CC is as follows: a structure or union
1133: which is 1, 2, 4 or 8 bytes long is returned like a scalar. A
1134: structure or union with any other size is stored into an address
1135: supplied by the caller in a special, fixed register.
1136:
1.1.1.7 root 1137: PCC usually handles all sizes of structures and unions by returning
1138: the address of a block of static storage containing the value.
1139: This method is not used in GNU CC because it is slower and
1140: nonreentrant.
1.1.1.3 root 1141:
1142: You can tell GNU CC to use the PCC convention with the option
1143: `-fpcc-struct-return'.
1144:
1.1.1.6 root 1145: There are also system-specific incompatibilities.
1146:
1.1.1.3 root 1147: * On the Sparc, GNU CC uses an incompatible calling convention for
1.1.1.7 root 1148: structures and unions. It passes them by including their contents
1149: in the argument list, whereas the standard compiler passes them
1.1.1.3 root 1150: effectively by reference.
1151:
1.1.1.7 root 1152: This is hard to fix in GCC version 1. GNU CC version 2 will use a
1153: compatible calling convention.
1154:
1155: The convention for structure or union returning is also
1156: incompatible, and `-fpcc-struct-return' does not help.
1157:
1158: System functions which can't be called properly from code compiled
1159: with GCC include `fetch', `store', `delete', `firstkey',
1160: `nextkey', `inet_makeaddr', `inet_lnaof', `inet_netof',
1161: `inet_ntoa', `mallinfo', `pmap_rmtcall', `clnt_call',
1162: `clntudp_bufcreate' and `clntudp_create'.
1163:
1164: * One consequence of the unusual calling convention used on the Sparc
1165: is that structures with less than word alignment do not work right
1166: when passed as arguments to varargs functions.
1167:
1168: It's not easy to fix this problem. In any case, it will be gone in
1169: version 2 as a result of the changed calling convention.
1170:
1171: * The Sparc version of `setjmp' interacts badly with unexpected stack
1172: adjustments. With rare exceptions, you cannot use `setjmp' in a
1173: function which moves the stack pointer.
1.1.1.6 root 1174:
1175: In the current version of GNU CC, there are three ways that the
1.1.1.7 root 1176: stack pointer can change value: (1) calls to `alloca', (2) use of
1177: variable-sized objects, and (3) calls to functions with parameters
1178: that do not all fit in the argument-passing registers (e.g., more
1179: than 6 parameters). You should avoid all three in functions that
1180: call `setjmp'.
1181:
1182: The cause of the problem is the way that Sun implemented register
1183: windows. The 64 bytes at addresses `%sp' through `%sp+63'
1184: correspond to the register window save area. When a register
1185: window must be spilled, its stack pointer is located, and the
1186: registers are dumped starting at that address. Similarly, when a
1187: register window must be restored, its stack pointer is located,
1188: and the registers are restored from that address.
1.1.1.6 root 1189:
1190: When `setjmp' is called, the current register window's registers
1191: are saved into the register save area, and when `longjmp' is
1192: called, they are restored (actually, *all* register windows are
1.1.1.7 root 1193: restored from all valid register windows at the time `longjmp' is
1194: called). If there is a change in the value of the stack pointer
1195: bewteen the `setjmp' and `longjmp' calls, when the registers are
1196: restored, they are restored with random values.
1.1.1.6 root 1197:
1.1.1.4 root 1198: * On Ultrix, the Fortran compiler expects registers 2 through 5 to
1.1.1.7 root 1199: be saved by function calls. However, the C compiler uses
1200: conventions compatible with BSD Unix: registers 2 through 5 may be
1201: clobbered by function calls.
1202:
1203: GNU CC uses the same convention as the Ultrix C compiler. You can
1204: use these options to produce code compatible with the Fortran
1205: compiler:
1.1.1.4 root 1206:
1207: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
1208:
1.1.1.6 root 1209: * DBX rejects some files produced by GNU CC, though it accepts
1.1.1.7 root 1210: similar constructs in output from PCC. Until someone can supply a
1211: coherent description of what is valid DBX input and what is not,
1212: there is nothing I can do about these problems. You are on your
1213: own.
1.1.1.2 root 1214:
1.1.1.6 root 1215:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.