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