![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-6 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-6 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
1.1 root 2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
1.1 root 10:
1.1.1.3 root 11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
1.1 root 14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
1.1.1.4 root 17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
1.1 root 22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
1.1.1.3 root 25: versions, except that the sections entitled "GNU General Public
1.1.1.4 root 26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
1.1 root 29:
30:
1.1.1.6 ! root 31: File: gcc.info, Node: Build Cross, Prev: Cross Runtime, Up: Cross-Compiler
! 32:
! 33: Actually Building the Cross-Compiler
! 34: ------------------------------------
! 35:
! 36: Now you can proceed just as for compiling a single-machine compiler
! 37: through the step of building stage 1. If you have not provided some
! 38: sort of `libgcc1.a', then compilation will give up at the point where
! 39: it needs that file, printing a suitable error message. If you do
! 40: provide `libgcc1.a', then building the compiler will automatically
! 41: compile and link a test program called `cross-test'; if you get errors
! 42: in the linking, it means that not all of the necessary routines in
! 43: `libgcc1.a' are available.
! 44:
! 45: If you are making a cross-compiler for an embedded system, and there
! 46: is no `stdio.h' header for it, then the compilation of `enquire' will
! 47: probably fail. The job of `enquire' is to run on the target machine
! 48: and figure out by experiment the nature of its floating point
! 49: representation. `enquire' records its findings in the header file
! 50: `float.h'. If you can't produce this file by running `enquire' on the
! 51: target machine, then you will need to come up with a suitable `float.h'
! 52: in some other way (or else, avoid using it in your programs).
! 53:
! 54: Do not try to build stage 2 for a cross-compiler. It doesn't work to
! 55: rebuild GNU CC as a cross-compiler using the cross-compiler, because
! 56: that would produce a program that runs on the target machine, not on the
! 57: host. For example, if you compile a 386-to-68030 cross-compiler with
! 58: itself, the result will not be right either for the 386 (because it was
! 59: compiled into 68030 code) or for the 68030 (because it was configured
! 60: for a 386 as the host). If you want to compile GNU CC into 68030 code,
! 61: whether you compile it on a 68030 or with a cross-compiler on a 386, you
! 62: must specify a 68030 as the host when you configure it.
! 63:
! 64: To install the cross-compiler, use `make install', as usual.
! 65:
! 66:
! 67: File: gcc.info, Node: PA Install, Next: Sun Install, Prev: Cross-Compiler, Up: Installation
! 68:
! 69: Installing on the HP Precision Architecture
! 70: ===========================================
! 71:
! 72: There are two variants of this CPU, called 1.0 and 1.1, which have
! 73: different machine descriptions. You must use the right one for your
! 74: machine. All 7NN machines and 8N7 machines use 1.1, while all other
! 75: 8NN machines use 1.0.
! 76:
! 77: The easiest way to handle this problem is to use `configure hpNNN'
! 78: or `configure hpNNN-hpux', where NNN is the model number of the
! 79: machine. Then `configure' will figure out if the machine is a 1.0 or
! 80: 1.1. Use `uname -a' to find out the model number of your machine.
! 81:
! 82: `-g' does not work on HP-UX, since that system uses a peculiar
! 83: debugging format which GNU CC does not know about. There are
! 84: preliminary versions of GAS and GDB for the HP-PA which do work with
! 85: GNU CC for debugging. You can get them by anonymous ftp from
! 86: `jaguar.cs.utah.edu' `dist' subdirectory. You would need to install
! 87: GAS in the file
! 88:
! 89: /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as
! 90:
! 91: where CONFIGURATION is the configuration name (perhaps `hpNNN-hpux')
! 92: and GCCVERSION is the GNU CC version number. Do this *before* starting
! 93: the build process, otherwise you will get errors from the HPUX
! 94: assembler while building `libgcc2.a'. The command
! 95:
! 96: make install-dir
! 97:
! 98: will create the necessary directory hierarchy so you can install GAS
! 99: before building GCC.
! 100:
! 101: If you obtained GAS before October 6, 1992 it is highly recommended
! 102: you get a new one to avoid several bugs which have been discovered
! 103: recently.
! 104:
! 105: To enable debugging, configure GNU CC with the `--gas' option before
! 106: building.
! 107:
! 108: It has been reported that GNU CC produces invalid assembly code for
! 109: 1.1 machines running HP-UX 8.02 when using the HP assembler. Typically
! 110: the errors look like this:
! 111: as: bug.s @line#15 [err#1060]
! 112: Argument 0 or 2 in FARG upper
! 113: - lookahead = ARGW1=FR,RTNVAL=GR
! 114: as: foo.s @line#28 [err#1060]
! 115: Argument 0 or 2 in FARG upper
! 116: - lookahead = ARGW1=FR
! 117:
! 118: You can check the version of HP-UX you are running by executing the
! 119: command `uname -r'. If you are indeed running HP-UX 8.02 on a PA and
! 120: using the HP assembler then configure GCC with "hpNNN-hpux8.02".
! 121:
! 122:
! 123: File: gcc.info, Node: Sun Install, Next: 3b1 Install, Prev: PA Install, Up: Installation
! 124:
! 125: Installing GNU CC on the Sun
! 126: ============================
! 127:
! 128: On Solaris (version 2.1), do not use the linker or other tools in
! 129: `/usr/ucb' to build GNU CC. Use `/usr/ccs/bin'.
! 130:
! 131: Make sure the environment variable `FLOAT_OPTION' is not set when
! 132: you compile `libgcc.a'. If this option were set to `f68881' when
! 133: `libgcc.a' is compiled, the resulting code would demand to be linked
! 134: with a special startup file and would not link properly without special
! 135: pains.
! 136:
! 137: The GNU compiler does not really support the Super SPARC processor
! 138: that is used in SPARC Station 10 and similar class machines. You can
! 139: get code that runs by specifying `sparc' as the cpu type; however, its
! 140: performance is not very good, and may vary widely according to the
! 141: compiler version and optimization options used. This is because the
! 142: instruction scheduling parameters designed for the Sparc are not correct
! 143: for the Super SPARC. Implementing scheduling parameters for the Super
! 144: SPARC might be a good project for someone who is willing to learn a
! 145: great deal about instruction scheduling in GNU CC.
! 146:
! 147: There is a bug in `alloca' in certain versions of the Sun library.
! 148: To avoid this bug, install the binaries of GNU CC that were compiled by
! 149: GNU CC. They use `alloca' as a built-in function and never the one in
! 150: the library.
! 151:
! 152: Some versions of the Sun compiler crash when compiling GNU CC. The
! 153: problem is a segmentation fault in cpp. This problem seems to be due to
! 154: the bulk of data in the environment variables. You may be able to avoid
! 155: it by using the following command to compile GNU CC with Sun CC:
! 156:
! 157: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
! 158:
! 159:
! 160: File: gcc.info, Node: 3b1 Install, Next: Unos Install, Prev: Sun Install, Up: Installation
! 161:
! 162: Installing GNU CC on the 3b1
! 163: ============================
! 164:
! 165: Installing GNU CC on the 3b1 is difficult if you do not already have
! 166: GNU CC running, due to bugs in the installed C compiler. However, the
! 167: following procedure might work. We are unable to test it.
! 168:
! 169: 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c'
! 170: and do `make cpp'. This makes a preliminary version of GNU cpp.
! 171:
! 172: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
! 173: file name.
! 174:
! 175: 3. Undo your change in `cccp.c', or reinstall the original version,
! 176: and do `make cpp' again.
! 177:
! 178: 4. Copy this final version of GNU cpp into `/lib/cpp'.
! 179:
! 180: 5. Replace every occurrence of `obstack_free' in the file `tree.c'
! 181: with `_obstack_free'.
! 182:
! 183: 6. Run `make' to get the first-stage GNU CC.
! 184:
! 185: 7. Reinstall the original version of `/lib/cpp'.
! 186:
! 187: 8. Now you can compile GNU CC with itself and install it in the normal
! 188: fashion.
! 189:
! 190:
! 191: File: gcc.info, Node: Unos Install, Next: VMS Install, Prev: 3b1 Install, Up: Installation
! 192:
! 193: Installing GNU CC on Unos
! 194: =========================
! 195:
! 196: Use `configure unos' for building on Unos.
! 197:
! 198: The Unos assembler is named `casm' instead of `as'. For some
! 199: strange reason linking `/bin/as' to `/bin/casm' changes the behavior,
! 200: and does not work. So, when installing GNU CC, you should install the
! 201: following script as `as' in the subdirectory where the passes of GCC
! 202: are installed:
! 203:
! 204: #!/bin/sh
! 205: casm $*
! 206:
! 207: The default Unos library is named `libunos.a' instead of `libc.a'.
! 208: To allow GNU CC to function, either change all references to `-lc' in
! 209: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'.
! 210:
! 211: When compiling GNU CC with the standard compiler, to overcome bugs in
! 212: the support of `alloca', do not use `-O' when making stage 2. Then use
! 213: the stage 2 compiler with `-O' to make the stage 3 compiler. This
! 214: compiler will have the same characteristics as the usual stage 2
! 215: compiler on other systems. Use it to make a stage 4 compiler and
! 216: compare that with stage 3 to verify proper compilation.
! 217:
! 218: (Perhaps simply defining `ALLOCA' in `x-crds' as described in the
! 219: comments there will make the above paragraph superfluous. Please
! 220: inform us of whether this works.)
! 221:
! 222: Unos uses memory segmentation instead of demand paging, so you will
! 223: need a lot of memory. 5 Mb is barely enough if no other tasks are
! 224: running. If linking `cc1' fails, try putting the object files into a
! 225: library and linking from that library.
! 226:
! 227:
1.1.1.5 root 228: File: gcc.info, Node: VMS Install, Next: WE32K Install, Prev: Unos Install, Up: Installation
1.1.1.2 root 229:
1.1.1.5 root 230: Installing GNU CC on VMS
231: ========================
1.1.1.2 root 232:
1.1.1.5 root 233: The VMS version of GNU CC is distributed in a backup saveset
234: containing both source code and precompiled binaries.
1.1.1.2 root 235:
1.1.1.5 root 236: To install the `gcc' command so you can use the compiler easily, in
237: the same manner as you use the VMS C compiler, you must install the VMS
238: CLD file for GNU CC as follows:
239:
240: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
241: point to the directories where the GNU CC executables
242: (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are
243: kept respectively. This should be done with the commands:
244:
245: $ assign /system /translation=concealed -
246: disk:[gcc.] gnu_cc
247: $ assign /system /translation=concealed -
248: disk:[gcc.include.] gnu_cc_include
249:
250: with the appropriate disk and directory names. These commands can
251: be placed in your system startup file so they will be executed
252: whenever the machine is rebooted. You may, if you choose, do this
253: via the `GCC_INSTALL.COM' script in the `[GCC]' directory.
254:
255: 2. Install the `GCC' command with the command line:
256:
257: $ set command /table=sys$common:[syslib]dcltables -
258: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc
259: $ install replace sys$common:[syslib]dcltables
260:
261: 3. To install the help file, do the following:
262:
263: $ library/help sys$library:helplib.hlb gcc.hlp
264:
265: Now you can invoke the compiler with a command like `gcc /verbose
266: file.c', which is equivalent to the command `gcc -v -c file.c' in
267: Unix.
268:
269: If you wish to use GNU C++ you must first install GNU CC, and then
270: perform the following steps:
271:
272: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the
273: directory where the preprocessor will search for the C++ header
274: files. This can be done with the command:
275:
276: $ assign /system /translation=concealed -
277: disk:[gcc.gxx_include.] gnu_gxx_include
278:
279: with the appropriate disk and directory name. If you are going to
280: be using libg++, this is where the libg++ install procedure will
281: install the libg++ header files.
282:
283: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same
284: directory that `gcc-cc1.exe' is kept.
285:
286: The GNU C++ compiler can be invoked with a command like `gcc /plus
287: /verbose file.cc', which is equivalent to the command `g++ -v -c
288: file.cc' in Unix.
289:
290: We try to put corresponding binaries and sources on the VMS
291: distribution tape. But sometimes the binaries will be from an older
292: version than the sources, because we don't always have time to update
293: them. (Use the `/version' option to determine the version number of
294: the binaries and compare it with the source file `version.c' to tell
295: whether this is so.) In this case, you should use the binaries you get
296: to recompile the sources. If you must recompile, here is how:
297:
298: 1. Execute the command procedure `vmsconfig.com' to set up the files
299: `tm.h', `config.h', `aux-output.c', and `md.', and to create files
300: `tconfig.h' and `hconfig.h'. This procedure also creates several
301: linker option files used by `make-cc1.com' and a data file used by
302: `make-l2.com'.
303:
304: $ @vmsconfig.com
305:
306: 2. Setup the logical names and command tables as defined above. In
307: addition, define the VMS logical name `GNU_BISON' to point at the
308: to the directories where the Bison executable is kept. This
309: should be done with the command:
310:
311: $ assign /system /translation=concealed -
312: disk:[bison.] gnu_bison
313:
314: You may, if you choose, use the `INSTALL_BISON.COM' script in the
315: `[BISON]' directory.
316:
317: 3. Install the `BISON' command with the command line:
318:
319: $ set command /table=sys$common:[syslib]dcltables -
320: /output=sys$common:[syslib]dcltables -
321: gnu_bison:[000000]bison
322: $ install replace sys$common:[syslib]dcltables
323:
324: 4. Type `@make-gcc' to recompile everything (alternatively, submit
325: the file `make-gcc.com' to a batch queue). If you wish to build
326: the GNU C++ compiler as well as the GNU CC compiler, you must
327: first edit `make-gcc.com' and follow the instructions that appear
328: in the comments.
329:
330: 5. In order to use GCC, you need a library of functions which GCC
331: compiled code will call to perform certain tasks, and these
332: functions are defined in the file `libgcc2.c'. To compile this
333: you should use the command procedure `make-l2.com', which will
334: generate the library `libgcc2.olb'. `libgcc2.olb' should be built
335: using the compiler built from the same distribution that
336: `libgcc2.c' came from, and `make-gcc.com' will automatically do
337: all of this for you.
338:
339: To install the library, use the following commands:
340:
341: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf)
342: $ library gnu_cc:[000000]gcclib/delete=L_*
343: $ library libgcc2/extract=*/output=libgcc2.obj
344: $ library gnu_cc:[000000]gcclib libgcc2.obj
345:
346: The first command simply removes old modules that will be replaced
347: with modules from `libgcc2' under different module names. The
348: modules `new' and `eprintf' may not actually be present in your
349: `gcclib.olb'--if the VMS librarian complains about those modules
350: not being present, simply ignore the message and continue on with
351: the next command. The second command removes the modules that
352: came from the previous version of the library `libgcc2.c'.
353:
354: Whenever you update the compiler on your system, you should also
355: update the library with the above procedure.
356:
357: 6. You may wish to build GCC in such a way that no files are written
358: to the directory where the source files reside. An example would
359: be the when the source files are on a read-only disk. In these
360: cases, execute the following DCL commands (substituting your
361: actual path names):
362:
363: $ assign dua0:[gcc.build_dir.]/translation=concealed, -
364: dua1:[gcc.source_dir.]/translation=concealed gcc_build
365: $ set default gcc_build:[000000]
366:
367: where the directory `dua1:[gcc.source_dir]' contains the source
368: code, and the directory `dua0:[gcc.build_dir]' is meant to contain
369: all of the generated object files and executables. Once you have
370: done this, you can proceed building GCC as described above. (Keep
371: in mind that `gcc_build' is a rooted logical name, and thus the
372: device names in each element of the search list must be an actual
373: physical device name rather than another rooted logical name).
374:
375: 7. *If you are building GNU CC with a previous version of GNU CC, you
376: also should check to see that you have the newest version of the
377: assembler*. In particular, GNU CC version 2 treats global constant
378: variables slightly differently from GNU CC version 1, and GAS
379: version 1.38.1 does not have the patches required to work with GCC
380: version 2. If you use GAS 1.38.1, then `extern const' variables
381: will not have the read-only bit set, and the linker will generate
382: warning messages about mismatched psect attributes for these
383: variables. These warning messages are merely a nuisance, and can
384: safely be ignored.
1.1.1.4 root 385:
1.1.1.5 root 386: If you are compiling with a version of GNU CC older than 1.33,
387: specify `/DEFINE=("inline=")' as an option in all the
388: compilations. This requires editing all the `gcc' commands in
389: `make-cc1.com'. (The older versions had problems supporting
390: `inline'.) Once you have a working 1.33 or newer GNU CC, you can
391: change this file back.
392:
393: 8. If you want to build GNU CC with the VAX C compiler, you will need
394: to make minor changes in `make-cccp.com' and `make-cc1.com' to
395: choose alternate definitions of `CC', `CFLAGS', and `LIBS'. See
396: comments in those files. However, you must also have a working
397: version of the GNU assembler (GNU as, aka GAS) as it is used as
398: the back-end for GNU CC to produce binary object modules and is
399: not included in the GNU CC sources. GAS is also needed to compile
400: `libgcc2' in order to build `gcclib' (see above); `make-l2.com'
401: expects to be able to find it operational in
402: `gnu_cc:[000000]gnu-as.exe'.
403:
404: To use GNU CC on VMS, you need the VMS driver programs `gcc.exe',
405: `gcc.com', and `gcc.cld'. They are distributed with the VMS
406: binaries (`gcc-vms') rather than the GNU CC sources. GAS is also
407: included in `gcc-vms', as is Bison.
408:
409: Once you have successfully built GNU CC with VAX C, you should use
410: the resulting compiler to rebuild itself. Before doing this, be
411: sure to restore the `CC', `CFLAGS', and `LIBS' definitions in
412: `make-cccp.com' and `make-cc1.com'. The second generation
413: compiler will be able to take advantage of many optimizations that
414: must be suppressed when building with other compilers.
415:
416: Under previous versions of GNU CC, the generated code would
417: occasionally give strange results when linked with the sharable
418: `VAXCRTL' library. Now this should work.
419:
420: Even with this version, however, GNU CC itself should not be linked
421: with the sharable `VAXCRTL'. The version of `qsort' in `VAXCRTL' has a
422: bug (known to be present in VMS versions V4.6 through V5.5) which
423: causes the compiler to fail.
424:
425: The executables are generated by `make-cc1.com' and `make-cccp.com'
426: use the object library version of `VAXCRTL' in order to make use of the
427: `qsort' routine in `gcclib.olb'. If you wish to link the compiler
428: executables with the shareable image version of `VAXCRTL', you should
429: edit the file `tm.h' (created by `vmsconfig.com') to define the macro
430: `QSORT_WORKAROUND'.
431:
432: `QSORT_WORKAROUND' is always defined when GNU CC is compiled with
433: VAX C, to avoid a problem in case `gcclib.olb' is not yet available.
434:
435:
436: File: gcc.info, Node: WE32K Install, Next: MIPS Install, Prev: VMS Install, Up: Installation
437:
438: Installing GNU CC on the WE32K
439: ==============================
440:
441: These computers are also known as the 3b2, 3b5, 3b20 and other
442: similar names. (However, the 3b1 is actually a 68000; see *Note 3b1
443: Install::.)
444:
445: Don't use `-g' when compiling with the system's compiler. The
446: system's linker seems to be unable to handle such a large program with
447: debugging information.
448:
449: The system's compiler runs out of capacity when compiling `stmt.c'
450: in GNU CC. You can work around this by building `cpp' in GNU CC first,
451: then use that instead of the system's preprocessor with the system's C
452: compiler to compile `stmt.c'. Here is how:
453:
454: mv /lib/cpp /lib/cpp.att
455: cp cpp /lib/cpp.gnu
1.1.1.6 ! root 456: echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp
1.1.1.5 root 457: chmod +x /lib/cpp
458:
459: The system's compiler produces bad code for some of the GNU CC
460: optimization files. So you must build the stage 2 compiler without
461: optimization. Then build a stage 3 compiler with optimization. That
462: executable should work. Here are the necessary commands:
463:
464: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g"
465: make stage2
466: make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"
467:
468: You may need to raise the ULIMIT setting to build a C++ compiler, as
469: the file `cc1plus' is larger than one megabyte.
470:
471:
472: File: gcc.info, Node: MIPS Install, Next: Collect2, Prev: WE32K Install, Up: Installation
473:
474: Installing GNU CC on the MIPS
475: =============================
476:
477: See *Note Installation:: about whether to use either of the options
478: `--with-stabs' or `--with-gnu-as'.
479:
480: The MIPS C compiler needs to be told to increase its table size for
481: switch statements with the `-Wf,-XNg1500' option in order to compile
482: `cp-parse.c'. If you use the `-O2' optimization option, you also need
483: to use `-Olimit 3000'. Both of these options are automatically
484: generated in the `Makefile' that the shell script `configure' builds.
485: If you override the `CC' make variable and use the MIPS compilers, you
486: may need to add `-Wf,-XNg1500 -Olimit 3000'.
487:
488: MIPS computers running RISC-OS can support four different
489: personalities: default, BSD 4.3, System V.3, and System V.4 (older
490: versions of RISC-OS don't support V.4). To configure GCC for these
491: platforms use the following configurations:
492:
493: `mips-mips-riscos`rev''
494: Default configuration for RISC-OS, revision `rev'.
495:
496: `mips-mips-riscos`rev'bsd'
497: BSD 4.3 configuration for RISC-OS, revision `rev'.
498:
499: `mips-mips-riscos`rev'sysv4'
500: System V.4 configuration for RISC-OS, revision `rev'.
501:
502: `mips-mips-riscos`rev'sysv'
503: System V.3 configuration for RISC-OS, revision `rev'.
504:
505: The revision `rev' mentioned above is the revision of RISC-OS to
506: use. You must reconfigure GCC when going from a RISC-OS revision 4 to
507: RISC-OS revision 5. This has the effect of avoiding a linker bug (see
508: *Note Installation Problems:: for more details).
509:
510: DECstations can support three different personalities: Ultrix, DEC
511: OSF/1, and OSF/rose. To configure GCC for these platforms use the
512: following configurations:
513:
514: `decstation-ultrix'
515: Ultrix configuration.
516:
517: `decstation-osf1'
518: Dec's version of OSF/1.
519:
520: `decstation-osfrose'
521: Open Software Foundation reference port of OSF/1 which uses the
522: OSF/rose object file format instead of ECOFF. Normally, you would
523: not select this configuration.
524:
525: On Irix version 4.0.5F, and perhaps on some other versions as well,
526: there is an assembler bug that reorders instructions incorrectly. To
527: work around it, specify the target configuration `mips-sgi-irix4loser'.
528: This configuration inhibits assembler optimization.
529:
530: You can turn off assembler optimization in a compiler configured with
531: target `mips-sgi-irix4' using the `-noasmopt' option. This compiler
532: option passes the option `-O0' to the assembler, to inhibit reordering.
533:
534: The `-noasmopt' option can be useful for testing whether a problem
535: is due to erroneous assembler reordering. Even if a problem does not go
536: away with `-noasmopt', it may still be due to assembler
537: reordering--perhaps GNU CC itself was miscompiled as a result.
538:
539: We know this is inconvenient, but it's the best that can be done at
540: the last minute.
541:
542:
1.1.1.6 ! root 543: File: gcc.info, Node: Collect2, Next: Header Dirs, Prev: MIPS Install, Up: Installation
1.1.1.5 root 544:
545: `collect2'
546: ==========
547:
548: Many target systems do not have support in the assembler and linker
549: for "constructors"--initialization functions to be called before the
550: official "start" of `main'. On such systems, GNU CC uses a utility
551: called `collect2' to arrange to call these functions at start time.
552:
553: The program `collect2' works by linking the program once and looking
554: through the linker output file for symbols with particular names
555: indicating they are constructor functions. If it finds any, it creates
556: a new temporary `.c' file containing a table of them, compiles it, and
557: links the program a second time including that file.
558:
559: The actual calls to the constructors are carried out by a subroutine
560: called `__main', which is called (automatically) at the beginning of
561: the body of `main' (provided `main' was compiled with GNU CC).
562:
563: The program `collect2' is installed as `ld' in the directory where
564: the passes of the compiler are installed. When `collect2' needs to
565: find the *real* `ld', it tries the following file names:
566:
567: * `gld' in the directories listed in the compiler's search
568: directories.
569:
570: * `gld' in the directories listed in the environment variable `PATH'.
571:
572: * `real-ld' in the compiler's search directories.
573:
574: * `real-ld' in `PATH'.
575:
576: * `ld' in `PATH'.
577:
578: "The compiler's search directories" means all the directories where
579: `gcc' searches for passes of the compiler. This includes directories
580: that you specify with `-B'.
581:
1.1.1.6 ! root 582: Cross-compilers search a little differently:
1.1.1.5 root 583:
584: * `gld' in the compiler's search directories.
585:
586: * `TARGET-gld' in `PATH'.
587:
588: * `real-ld' in the compiler's search directories.
589:
590: * `TARGET-real-ld' in `PATH'.
591:
592: * `TARGET-ld' in `PATH'.
593:
594: `collect2' does not search for `ld' using the compiler's search
595: directories, because if it did, it would find itself--not the real
596: `ld'--and this could lead to infinite recursion. However, the
597: directory where `collect2' is installed might happen to be in `PATH'.
598: That could lead `collect2' to invoke itself anyway. when looking for
599: `ld'.
600:
601: To prevent this, `collect2' explicitly avoids running `ld' using the
602: file name under which `collect2' itself was invoked. In fact, it
603: remembers up to two such names--in case one copy of `collect2' finds
604: another copy (or version) of `collect2' installed as `ld' in a second
605: place in the search path.
606:
607: If two file names to avoid are not sufficient, you may still
608: encounter an infinite recursion of `collect2' processes. When this
609: happens. check all the files installed as `ld' in any of the
610: directories searched, and straighten out the situation.
611:
612: (In a future version, we will probably change `collect2' to avoid
613: any reinvocation of a file from which any parent `collect2' was run.)
614:
615:
1.1.1.6 ! root 616: File: gcc.info, Node: Header Dirs, Prev: Collect2, Up: Installation
! 617:
! 618: Standard Header File Directories
! 619: ================================
! 620:
! 621: `GCC_INCLUDE_DIR' means the same thing for native and cross. It is
! 622: where GNU CC stores its private include files, and also where GNU CC
! 623: stores the fixed include files. A cross compiled GNU CC runs
! 624: `fixincludes' on the header files in `$(tooldir)/include'. (If the
! 625: cross compilation header files need to be fixed, they must be installed
! 626: before GNU CC is built. If the cross compilation header files are
! 627: already suitable for ANSI C and GNU CC, nothing special need be done).
! 628:
! 629: `GPLUS_INCLUDE_DIR' means the same thing for native and cross. It
! 630: is where `g++' looks first for header files. `libg++' installs only
! 631: target independent header files in that directory.
! 632:
! 633: `LOCAL_INCLUDE_DIR' is used only for a native compiler. It is
! 634: normally `/usr/local/include'. GNU CC searches this directory so that
! 635: users can install header files in `/usr/local/include'.
! 636:
! 637: `CROSS_INCLUDE_DIR' is used only for a cross compiler. GNU CC
! 638: doesn't install anything there.
! 639:
! 640: `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It
! 641: is the place for other packages to install header files that GNU CC will
! 642: use. For a cross-compiler, this is the equivalent of `/usr/include'.
! 643: When you build a cross-compiler, `fixincludes' processes any header
! 644: files in this directory.
! 645:
! 646:
1.1.1.5 root 647: File: gcc.info, Node: C Extensions, Next: C++ Extensions, Prev: Installation, Up: Top
648:
649: Extensions to the C Language Family
650: ***********************************
651:
652: GNU C provides several language features not found in ANSI standard
653: C. (The `-pedantic' option directs GNU CC to print a warning message if
654: any of these features is used.) To test for the availability of these
655: features in conditional compilation, check for a predefined macro
656: `__GNUC__', which is always defined under GNU CC.
657:
658: These extensions are available in C and in the languages derived from
659: it, C++ and Objective C. *Note Extensions to the C++ Language: C++
660: Extensions, for extensions that apply *only* to C++.
661:
662: * Menu:
663:
664: * Statement Exprs:: Putting statements and declarations inside expressions.
665: * Local Labels:: Labels local to a statement-expression.
666: * Labels as Values:: Getting pointers to labels, and computed gotos.
667: * Nested Functions:: As in Algol and Pascal, lexical scoping of functions.
668: * Constructing Calls:: Dispatching a call to another function.
669: * Naming Types:: Giving a name to the type of some expression.
670: * Typeof:: `typeof': referring to the type of an expression.
671: * Lvalues:: Using `?:', `,' and casts in lvalues.
672: * Conditionals:: Omitting the middle operand of a `?:' expression.
673: * Long Long:: Double-word integers--`long long int'.
1.1.1.6 ! root 674: * Complex:: Data types for complex numbers.
1.1.1.5 root 675: * Zero Length:: Zero-length arrays.
676: * Variable Length:: Arrays whose length is computed at run time.
677: * Macro Varargs:: Macros with variable number of arguments.
678: * Subscripting:: Any array can be subscripted, even if not an lvalue.
679: * Pointer Arith:: Arithmetic on `void'-pointers and function pointers.
680: * Initializers:: Non-constant initializers.
681: * Constructors:: Constructor expressions give structures, unions
682: or arrays as values.
683: * Labeled Elements:: Labeling elements of initializers.
684: * Cast to Union:: Casting to union type from any member of the union.
685: * Case Ranges:: `case 1 ... 9' and such.
686: * Function Attributes:: Declaring that functions have no side effects,
687: or that they can never return.
688: * Function Prototypes:: Prototype declarations and old-style definitions.
689: * Dollar Signs:: Dollar sign is allowed in identifiers.
690: * Character Escapes:: `\e' stands for the character ESC.
691: * Variable Attributes:: Specifying attributes of variables.
692: * Alignment:: Inquiring about the alignment of a type or variable.
693: * Inline:: Defining inline functions (as fast as macros).
694: * Extended Asm:: Assembler instructions with C expressions as operands.
695: (With them you can define "built-in" functions.)
696: * Asm Labels:: Specifying the assembler name to use for a C symbol.
697: * Explicit Reg Vars:: Defining variables residing in specified registers.
698: * Alternate Keywords:: `__const__', `__asm__', etc., for header files.
699: * Incomplete Enums:: `enum foo;', with details to follow.
700: * Function Names:: Printable strings which are the name of the current
701: function.
702:
703:
704: File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: C Extensions
705:
706: Statements and Declarations in Expressions
707: ==========================================
1.1.1.4 root 708:
1.1.1.5 root 709: A compound statement enclosed in parentheses may appear as an
710: expression in GNU C. This allows you to use loops, switches, and local
711: variables within an expression.
712:
713: Recall that a compound statement is a sequence of statements
714: surrounded by braces; in this construct, parentheses go around the
715: braces. For example:
716:
717: ({ int y = foo (); int z;
718: if (y > 0) z = y;
719: else z = - y;
720: z; })
721:
722: is a valid (though slightly more complex than necessary) expression for
723: the absolute value of `foo ()'.
724:
725: The last thing in the compound statement should be an expression
726: followed by a semicolon; the value of this subexpression serves as the
727: value of the entire construct. (If you use some other kind of statement
728: last within the braces, the construct has type `void', and thus
729: effectively no value.)
730:
731: This feature is especially useful in making macro definitions "safe"
732: (so that they evaluate each operand exactly once). For example, the
733: "maximum" function is commonly defined as a macro in standard C as
734: follows:
735:
736: #define max(a,b) ((a) > (b) ? (a) : (b))
737:
738: But this definition computes either A or B twice, with bad results if
739: the operand has side effects. In GNU C, if you know the type of the
740: operands (here let's assume `int'), you can define the macro safely as
741: follows:
742:
743: #define maxint(a,b) \
744: ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
745:
746: Embedded statements are not allowed in constant expressions, such as
747: the value of an enumeration constant, the width of a bit field, or the
748: initial value of a static variable.
749:
750: If you don't know the type of the operand, you can still do this,
751: but you must use `typeof' (*note Typeof::.) or type naming (*note
752: Naming Types::.).
1.1.1.2 root 753:
1.1.1.4 root 754:
1.1.1.5 root 755: File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: C Extensions
1.1.1.2 root 756:
1.1.1.5 root 757: Locally Declared Labels
758: =======================
759:
760: Each statement expression is a scope in which "local labels" can be
761: declared. A local label is simply an identifier; you can jump to it
762: with an ordinary `goto' statement, but only from within the statement
763: expression it belongs to.
764:
765: A local label declaration looks like this:
766:
767: __label__ LABEL;
768:
769: or
770:
771: __label__ LABEL1, LABEL2, ...;
772:
773: Local label declarations must come at the beginning of the statement
774: expression, right after the `({', before any ordinary declarations.
1.1.1.2 root 775:
1.1.1.5 root 776: The label declaration defines the label *name*, but does not define
777: the label itself. You must do this in the usual way, with `LABEL:',
778: within the statements of the statement expression.
779:
780: The local label feature is useful because statement expressions are
781: often used in macros. If the macro contains nested loops, a `goto' can
782: be useful for breaking out of them. However, an ordinary label whose
783: scope is the whole function cannot be used: if the macro can be
784: expanded several times in one function, the label will be multiply
785: defined in that function. A local label avoids this problem. For
1.1.1.4 root 786: example:
787:
1.1.1.5 root 788: #define SEARCH(array, target) \
789: ({ \
790: __label__ found; \
791: typeof (target) _SEARCH_target = (target); \
792: typeof (*(array)) *_SEARCH_array = (array); \
793: int i, j; \
794: int value; \
795: for (i = 0; i < max; i++) \
796: for (j = 0; j < max; j++) \
797: if (_SEARCH_array[i][j] == _SEARCH_target) \
798: { value = i; goto found; } \
799: value = -1; \
800: found: \
801: value; \
802: })
803:
804:
805: File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: C Extensions
806:
807: Labels as Values
808: ================
809:
810: You can get the address of a label defined in the current function
811: (or a containing function) with the unary operator `&&'. The value has
812: type `void *'. This value is a constant and can be used wherever a
813: constant of that type is valid. For example:
814:
815: void *ptr;
816: ...
817: ptr = &&foo;
818:
819: To use these values, you need to be able to jump to one. This is
820: done with the computed goto statement(1), `goto *EXP;'. For example,
821:
822: goto *ptr;
823:
824: Any expression of type `void *' is allowed.
825:
826: One way of using these constants is in initializing a static array
827: that will serve as a jump table:
828:
829: static void *array[] = { &&foo, &&bar, &&hack };
830:
831: Then you can select a label with indexing, like this:
832:
833: goto *array[i];
834:
835: Note that this does not check whether the subscript is in bounds--array
836: indexing in C never does that.
837:
838: Such an array of label values serves a purpose much like that of the
839: `switch' statement. The `switch' statement is cleaner, so use that
840: rather than an array unless the problem does not fit a `switch'
841: statement very well.
842:
843: Another use of label values is in an interpreter for threaded code.
844: The labels within the interpreter function can be stored in the
845: threaded code for super-fast dispatching.
846:
847: You can use this mechanism to jump to code in a different function.
848: If you do that, totally unpredictable things will happen. The best way
849: to avoid this is to store the label address only in automatic variables
850: and never pass it as an argument.
851:
852: ---------- Footnotes ----------
853:
854: (1) The analogous feature in Fortran is called an assigned goto,
855: but that name seems inappropriate in C, where one can do more than
856: simply store label addresses in label variables.
857:
858:
859: File: gcc.info, Node: Nested Functions, Next: Constructing Calls, Prev: Labels as Values, Up: C Extensions
860:
861: Nested Functions
862: ================
863:
864: A "nested function" is a function defined inside another function.
865: (Nested functions are not supported for GNU C++.) The nested function's
866: name is local to the block where it is defined. For example, here we
867: define a nested function named `square', and call it twice:
868:
869: foo (double a, double b)
870: {
871: double square (double z) { return z * z; }
1.1.1.4 root 872:
1.1.1.5 root 873: return square (a) + square (b);
874: }
875:
876: The nested function can access all the variables of the containing
877: function that are visible at the point of its definition. This is
878: called "lexical scoping". For example, here we show a nested function
879: which uses an inherited variable named `offset':
880:
881: bar (int *array, int offset, int size)
882: {
883: int access (int *array, int index)
884: { return array[index + offset]; }
885: int i;
886: ...
887: for (i = 0; i < size; i++)
888: ... access (array, i) ...
889: }
890:
891: Nested function definitions are permitted within functions in the
892: places where variable definitions are allowed; that is, in any block,
893: before the first statement in the block.
894:
895: It is possible to call the nested function from outside the scope of
896: its name by storing its address or passing the address to another
897: function:
898:
899: hack (int *array, int size)
1.1.1.4 root 900: {
1.1.1.5 root 901: void store (int index, int value)
902: { array[index] = value; }
903:
904: intermediate (store, size);
1.1.1.4 root 905: }
906:
1.1.1.5 root 907: Here, the function `intermediate' receives the address of `store' as
908: an argument. If `intermediate' calls `store', the arguments given to
909: `store' are used to store into `array'. But this technique works only
910: so long as the containing function (`hack', in this example) does not
1.1.1.6 ! root 911: exit.
! 912:
! 913: If you try to call the nested function through its address after the
! 914: containing function has exited, all hell will break loose. If you try
! 915: to call it after a containing scope level has exited, and if it refers
! 916: to some of the variables that are no longer in scope, you may be lucky,
! 917: but it's not wise to take the risk. If, however, the nested function
! 918: does not refer to anything that has gone out of scope, you should be
! 919: safe.
1.1.1.5 root 920:
921: GNU CC implements taking the address of a nested function using a
922: technique called "trampolines". A paper describing them is available
923: from `maya.idiap.ch' in directory `pub/tmb', file `usenix88-lexic.ps.Z'.
924:
925: A nested function can jump to a label inherited from a containing
926: function, provided the label was explicitly declared in the containing
927: function (*note Local Labels::.). Such a jump returns instantly to the
928: containing function, exiting the nested function which did the `goto'
929: and any intermediate functions as well. Here is an example:
1.1.1.4 root 930:
1.1.1.5 root 931: bar (int *array, int offset, int size)
932: {
933: __label__ failure;
934: int access (int *array, int index)
935: {
936: if (index > size)
937: goto failure;
938: return array[index + offset];
939: }
940: int i;
941: ...
942: for (i = 0; i < size; i++)
943: ... access (array, i) ...
944: ...
945: return 0;
1.1.1.4 root 946:
1.1.1.5 root 947: /* Control comes here from `access'
948: if it detects an error. */
949: failure:
950: return -1;
951: }
952:
953: A nested function always has internal linkage. Declaring one with
954: `extern' is erroneous. If you need to declare the nested function
955: before its definition, use `auto' (which is otherwise meaningless for
956: function declarations).
957:
958: bar (int *array, int offset, int size)
1.1.1.4 root 959: {
1.1.1.5 root 960: __label__ failure;
961: auto int access (int *, int);
962: ...
963: int access (int *array, int index)
964: {
965: if (index > size)
966: goto failure;
967: return array[index + offset];
968: }
969: ...
1.1.1.4 root 970: }
1.1.1.2 root 971:
972:
1.1.1.5 root 973: File: gcc.info, Node: Constructing Calls, Next: Naming Types, Prev: Nested Functions, Up: C Extensions
1.1 root 974:
1.1.1.5 root 975: Constructing Function Calls
976: ===========================
1.1 root 977:
1.1.1.5 root 978: Using the built-in functions described below, you can record the
979: arguments a function received, and call another function with the same
980: arguments, without knowing the number or types of the arguments.
981:
982: You can also record the return value of that function call, and
983: later return that value, without knowing what data type the function
984: tried to return (as long as your caller expects that data type).
985:
986: `__builtin_apply_args ()'
987: This built-in function returns a pointer of type `void *' to data
988: describing how to perform a call with the same arguments as were
989: passed to the current function.
990:
991: The function saves the arg pointer register, structure value
992: address, and all registers that might be used to pass arguments to
993: a function into a block of memory allocated on the stack. Then it
994: returns the address of that block.
995:
996: `__builtin_apply (FUNCTION, ARGUMENTS, SIZE)'
997: This built-in function invokes FUNCTION (type `void (*)()') with a
998: copy of the parameters described by ARGUMENTS (type `void *') and
999: SIZE (type `int').
1000:
1001: The value of ARGUMENTS should be the value returned by
1002: `__builtin_apply_args'. The argument SIZE specifies the size of
1003: the stack argument data, in bytes.
1004:
1005: This function returns a pointer of type `void *' to data describing
1006: how to return whatever value was returned by FUNCTION. The data
1007: is saved in a block of memory allocated on the stack.
1008:
1009: It is not always simple to compute the proper value for SIZE. The
1010: value is used by `__builtin_apply' to compute the amount of data
1011: that should be pushed on the stack and copied from the incoming
1012: argument area.
1013:
1014: `__builtin_return (RESULT)'
1015: This built-in function returns the value described by RESULT from
1016: the containing function. You should specify, for RESULT, a value
1017: returned by `__builtin_apply'.
1.1.1.3 root 1018:
1.1.1.5 root 1019:
1020: File: gcc.info, Node: Naming Types, Next: Typeof, Prev: Constructing Calls, Up: C Extensions
1.1.1.4 root 1021:
1.1.1.5 root 1022: Naming an Expression's Type
1023: ===========================
1.1.1.4 root 1024:
1.1.1.5 root 1025: You can give a name to the type of an expression using a `typedef'
1026: declaration with an initializer. Here is how to define NAME as a type
1027: name for the type of EXP:
1028:
1029: typedef NAME = EXP;
1030:
1031: This is useful in conjunction with the statements-within-expressions
1032: feature. Here is how the two together can be used to define a safe
1033: "maximum" macro that operates on any arithmetic type:
1034:
1035: #define max(a,b) \
1036: ({typedef _ta = (a), _tb = (b); \
1037: _ta _a = (a); _tb _b = (b); \
1038: _a > _b ? _a : _b; })
1039:
1040: The reason for using names that start with underscores for the local
1041: variables is to avoid conflicts with variable names that occur within
1042: the expressions that are substituted for `a' and `b'. Eventually we
1043: hope to design a new form of declaration syntax that allows you to
1044: declare variables whose scopes start only after their initializers;
1045: this will be a more reliable way to prevent such conflicts.
1.1.1.3 root 1046:
1047:
1.1.1.5 root 1048: File: gcc.info, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: C Extensions
1.1.1.3 root 1049:
1.1.1.5 root 1050: Referring to a Type with `typeof'
1051: =================================
1052:
1053: Another way to refer to the type of an expression is with `typeof'.
1054: The syntax of using of this keyword looks like `sizeof', but the
1055: construct acts semantically like a type name defined with `typedef'.
1056:
1057: There are two ways of writing the argument to `typeof': with an
1058: expression or with a type. Here is an example with an expression:
1.1.1.3 root 1059:
1.1.1.5 root 1060: typeof (x[0](1))
1061:
1062: This assumes that `x' is an array of functions; the type described is
1063: that of the values of the functions.
1064:
1065: Here is an example with a typename as the argument:
1066:
1067: typeof (int *)
1068:
1069: Here the type described is that of pointers to `int'.
1070:
1071: If you are writing a header file that must work when included in
1072: ANSI C programs, write `__typeof__' instead of `typeof'. *Note
1073: Alternate Keywords::.
1074:
1075: A `typeof'-construct can be used anywhere a typedef name could be
1076: used. For example, you can use it in a declaration, in a cast, or
1077: inside of `sizeof' or `typeof'.
1078:
1079: * This declares `y' with the type of what `x' points to.
1080:
1081: typeof (*x) y;
1082:
1083: * This declares `y' as an array of such values.
1084:
1085: typeof (*x) y[4];
1086:
1087: * This declares `y' as an array of pointers to characters:
1088:
1089: typeof (typeof (char *)[4]) y;
1090:
1091: It is equivalent to the following traditional C declaration:
1092:
1093: char *y[4];
1094:
1095: To see the meaning of the declaration using `typeof', and why it
1096: might be a useful way to write, let's rewrite it with these macros:
1097:
1098: #define pointer(T) typeof(T *)
1099: #define array(T, N) typeof(T [N])
1100:
1101: Now the declaration can be rewritten this way:
1102:
1103: array (pointer (char), 4) y;
1104:
1105: Thus, `array (pointer (char), 4)' is the type of arrays of 4
1106: pointers to `char'.
1.1.1.3 root 1107:
1.1.1.4 root 1108:
1.1.1.5 root 1109: File: gcc.info, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: C Extensions
1110:
1111: Generalized Lvalues
1112: ===================
1113:
1114: Compound expressions, conditional expressions and casts are allowed
1115: as lvalues provided their operands are lvalues. This means that you
1116: can take their addresses or store values into them.
1117:
1118: For example, a compound expression can be assigned, provided the last
1119: expression in the sequence is an lvalue. These two expressions are
1120: equivalent:
1121:
1122: (a, b) += 5
1123: a, (b += 5)
1124:
1125: Similarly, the address of the compound expression can be taken.
1126: These two expressions are equivalent:
1127:
1128: &(a, b)
1129: a, &b
1130:
1131: A conditional expression is a valid lvalue if its type is not void
1132: and the true and false branches are both valid lvalues. For example,
1133: these two expressions are equivalent:
1134:
1135: (a ? b : c) = 5
1136: (a ? b = 5 : (c = 5))
1.1.1.3 root 1137:
1.1.1.5 root 1138: A cast is a valid lvalue if its operand is an lvalue. A simple
1139: assignment whose left-hand side is a cast works by converting the
1140: right-hand side first to the specified type, then to the type of the
1141: inner left-hand side expression. After this is stored, the value is
1142: converted back to the specified type to become the value of the
1143: assignment. Thus, if `a' has type `char *', the following two
1144: expressions are equivalent:
1.1.1.3 root 1145:
1.1.1.5 root 1146: (int)a = 5
1147: (int)(a = (char *)(int)5)
1.1.1.4 root 1148:
1.1.1.5 root 1149: An assignment-with-arithmetic operation such as `+=' applied to a
1150: cast performs the arithmetic using the type resulting from the cast,
1151: and then continues as in the previous case. Therefore, these two
1152: expressions are equivalent:
1.1.1.4 root 1153:
1.1.1.5 root 1154: (int)a += 5
1155: (int)(a = (char *)(int) ((int)a + 5))
1.1.1.4 root 1156:
1.1.1.5 root 1157: You cannot take the address of an lvalue cast, because the use of its
1158: address would not work out coherently. Suppose that `&(int)f' were
1159: permitted, where `f' has type `float'. Then the following statement
1160: would try to store an integer bit-pattern where a floating point number
1161: belongs:
1.1.1.4 root 1162:
1.1.1.5 root 1163: *&(int)f = 1;
1.1.1.4 root 1164:
1.1.1.5 root 1165: This is quite different from what `(int)f = 1' would do--that would
1166: convert 1 to floating point and store it. Rather than cause this
1167: inconsistency, we think it is better to prohibit use of `&' on a cast.
1.1.1.3 root 1168:
1.1.1.5 root 1169: If you really do want an `int *' pointer with the address of `f',
1170: you can simply write `(int *)&f'.
1.1.1.3 root 1171:
1172:
1.1.1.5 root 1173: File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Lvalues, Up: C Extensions
1.1.1.3 root 1174:
1.1.1.5 root 1175: Conditionals with Omitted Operands
1.1.1.4 root 1176: ==================================
1.1.1.3 root 1177:
1.1.1.5 root 1178: The middle operand in a conditional expression may be omitted. Then
1179: if the first operand is nonzero, its value is the value of the
1180: conditional expression.
1.1.1.4 root 1181:
1.1.1.5 root 1182: Therefore, the expression
1.1.1.4 root 1183:
1.1.1.5 root 1184: x ? : y
1185:
1186: has the value of `x' if that is nonzero; otherwise, the value of `y'.
1187:
1188: This example is perfectly equivalent to
1189:
1190: x ? x : y
1191:
1192: In this simple case, the ability to omit the middle operand is not
1193: especially useful. When it becomes useful is when the first operand
1194: does, or may (if it is a macro argument), contain a side effect. Then
1195: repeating the operand in the middle would perform the side effect
1196: twice. Omitting the middle operand uses the value already computed
1197: without the undesirable effects of recomputing it.
1198:
1199:
1.1.1.6 ! root 1200: File: gcc.info, Node: Long Long, Next: Complex, Prev: Conditionals, Up: C Extensions
1.1.1.5 root 1201:
1202: Double-Word Integers
1203: ====================
1204:
1205: GNU C supports data types for integers that are twice as long as
1206: `long int'. Simply write `long long int' for a signed integer, or
1207: `unsigned long long int' for an unsigned integer. To make an integer
1208: constant of type `long long int', add the suffix `LL' to the integer.
1209: To make an integer constant of type `unsigned long long int', add the
1210: suffix `ULL' to the integer.
1211:
1212: You can use these types in arithmetic like any other integer types.
1213: Addition, subtraction, and bitwise boolean operations on these types
1214: are open-coded on all types of machines. Multiplication is open-coded
1215: if the machine supports fullword-to-doubleword a widening multiply
1216: instruction. Division and shifts are open-coded only on machines that
1217: provide special support. The operations that are not open-coded use
1218: special library routines that come with GNU CC.
1219:
1220: There may be pitfalls when you use `long long' types for function
1221: arguments, unless you declare function prototypes. If a function
1222: expects type `int' for its argument, and you pass a value of type `long
1223: long int', confusion will result because the caller and the subroutine
1224: will disagree about the number of bytes for the argument. Likewise, if
1225: the function expects `long long int' and you pass `int'. The best way
1226: to avoid such problems is to use prototypes.
1227:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.