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