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