![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-4 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-4 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.2 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.44 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: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 8: Permission is granted to make and distribute verbatim copies of 9: this manual provided the copyright notice and this permission notice 10: are preserved on all copies. 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 14: that the section entitled "GNU General Public License" is included 15: exactly as in the original, and provided that the entire resulting 16: derived work is distributed under the terms of a permission notice 17: identical to this one. 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 21: versions, except that the section entitled "GNU General Public 22: License" and this permission notice may be included in translations 23: approved by the Free Software Foundation instead of in the original 24: English. 25: 26: 1.1.1.2 ! root 27: File: gcc.info, Node: Unos Install, Next: VMS Install, Prev: 3b1 Install, Up: Installation ! 28: ! 29: Installing GNU CC on Unos ! 30: ========================= ! 31: ! 32: Use `configure unos' for building on Unos. ! 33: ! 34: The Unos assembler is named `casm' instead of `as'. For some ! 35: strange reason linking `/bin/as' to `/bin/casm' changes the behavior, ! 36: and does not work. So, when installing GNU CC, you should install the ! 37: following script as `as' in the subdirectory where the passes of GCC ! 38: are installed: ! 39: ! 40: #!/bin/sh ! 41: casm $* ! 42: ! 43: The default Unos library is named `libunos.a' instead of `libc.a'. ! 44: To allow GNU CC to function, either change all references to `-lc' in ! 45: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'. ! 46: ! 47: When compiling GNU CC with the standard compiler, to overcome bugs ! 48: in the support of `alloca', do not use `-O' when making stage 2. Then ! 49: use the stage 2 compiler with `-O' to make the stage 3 compiler. This ! 50: compiler will have the same characteristics as the usual stage 2 ! 51: compiler on other systems. Use it to make a stage 4 compiler and ! 52: compare that with stage 3 to verify proper compilation. ! 53: ! 54: Unos uses memory segmentation instead of demand paging, so you will ! 55: need a lot of memory. 5 Mb is barely enough if no other tasks are ! 56: running. If linking `cc1' fails, try putting the object files into a ! 57: library and linking from that library. ! 58: ! 59: 1.1 root 60: File: gcc.info, Node: VMS Install, Prev: Unos Install, Up: Installation 61: 62: Installing GNU CC on VMS 63: ======================== 64: 65: The VMS version of GNU CC is distributed in a backup saveset 66: containing both source code and precompiled binaries. 67: 68: To install the `gcc' command so you can use the compiler easily, in 69: the same manner as you use the VMS C compiler, you must install the 70: VMS CLD file for GNU CC as follows: 71: 72: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to 73: point to the directories where the GNU CC executables (`gcc-cpp', 74: `gcc-cc1', etc.) and the C include files are kept. This should 75: be done with the commands: 76: 1.1.1.2 ! root 77: $ assign /system /translation=concealed - ! 78: disk:[gcc.] gnu_cc ! 79: $ assign /system /translation=concealed - ! 80: disk:[gcc.include.] gnu_cc_include 1.1 root 81: 82: with the appropriate disk and directory names. These commands 83: can be placed in your system startup file so they will be 84: executed whenever the machine is rebooted. You may, if you 85: choose, do this via the `GCC_INSTALL.COM' script in the `[GCC]' 86: directory. 87: 88: 2. Install the `GCC' command with the command line: 89: 1.1.1.2 ! root 90: $ set command /table=sys$common:[syslib]dcltables - ! 91: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc ! 92: $ install replace sys$common:[syslib]dcltables 1.1 root 93: 94: 3. To install the help file, do the following: 95: 96: $ lib/help sys$library:helplib.hlb gcc.hlp 97: 98: Now you can invoke the compiler with a command like `gcc /verbose 99: file.c', which is equivalent to the command `gcc -v -c file.c' in 100: Unix. 101: 102: If you wish to use GNU C++ you must first install GNU CC, and then 103: perform the following steps: 104: 105: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the 106: directory where the preprocessor will search for the C++ header 107: files. This can be done with the command: 108: 1.1.1.2 ! root 109: $ assign /system /translation=concealed - ! 110: disk:[gcc.gxx_include.] gnu_gxx_include 1.1 root 111: 112: with the appropriate disk and directory name. If you are going 1.1.1.2 ! root 113: to be using libg++, this is where the libg++ install procedure ! 114: will install the libg++ header files. 1.1 root 115: 116: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same 117: directory that `gcc-cc1.exe' is kept. 118: 119: The GNU C++ compiler can be invoked with a command like `gcc 120: /plus /verbose file.cc', which is equivalent to the command `g++ 121: -v -c file.cc' in Unix. 122: 123: We try to put corresponding binaries and sources on the VMS 124: distribution tape. But sometimes the binaries will be from an older 125: version that the sources, because we don't always have time to update 126: them. (Use the `/version' option to determine the version number of 127: the binaries and compare it with the source file `version.c' to tell 128: whether this is so.) In this case, you should use the binaries you 129: get to recompile the sources. If you must recompile, here is how: 130: 131: 1. Copy the file `vms.h' to `tm.h', `xm-vms.h' to `config.h', 132: `vax.md' to `md.' and `vax.c' to `aux-output.c'. The files to be 133: copied are found in the subdirectory named `config'; they should 134: be copied to the main directory of GNU CC. If you wish, you may 135: use the command file `config-gcc.com' to perform these steps for 136: you. 137: 138: 2. Setup the logical names and command tables as defined above. In 139: addition, define the VMS logical name `GNU_BISON' to point at the 140: to the directories where the Bison executable is kept. This 141: should be done with the command: 142: 1.1.1.2 ! root 143: $ assign /system /translation=concealed - ! 144: disk:[bison.] gnu_bison 1.1 root 145: 146: You may, if you choose, use the `INSTALL_BISON.COM' script in 147: the `[BISON]' directory. 148: 149: 3. Install the `BISON' command with the command line: 150: 1.1.1.2 ! root 151: $ set command /table=sys$common:[syslib]dcltables - ! 152: /output=sys$common:[syslib]dcltables - ! 153: gnu_bison:[000000]bison ! 154: $ install replace sys$common:[syslib]dcltables 1.1 root 155: 156: 4. Type `@make-gcc' to recompile everything (alternatively, you may 157: submit the file `make-gcc.com' to a batch queue). If you wish to 158: build the GNU C++ compiler as well as the GNU CC compiler, you 159: must first edit `make-gcc.com' and follow the instructions that 160: appear in the comments. 161: 1.1.1.2 ! root 162: 5. In order to use GCC, you need a library of functions which GCC ! 163: compiled code will call to perform certain tasks, and these ! 164: functions are defined in the file `libgcc2.c'. To compile this ! 165: you should use the command procedure `make-l2.com', which will ! 166: generate the library `libgcc2.olb'. `libgcc2.olb' should be ! 167: built using the compiler built from the same distribution that ! 168: `libgcc2.c' came from, and `make-gcc.com' will automatically do ! 169: all of this for you. ! 170: ! 171: To install the library, use the following commands: ! 172: ! 173: $ lib gnu_cc:[000000]gcclib/delete=(new,eprintf) ! 174: $ lib libgcc2/extract=*/output=libgcc2.obj ! 175: $ lib gnu_cc:[000000]gcclib libgcc2.obj ! 176: ! 177: The first command simply removes old modules that will be ! 178: replaced with modules from libgcc2. If the VMS librarian ! 179: complains about those modules not being present, simply ignore ! 180: the message and continue on with the next command. ! 181: ! 182: Whenever you update the compiler on your system, you should ! 183: also update the library with the above procedure. ! 184: 1.1 root 185: *If you are building GNU CC with a previous version of GNU CC, 186: you also should check to see that you have the newest version of 187: the assembler*. In particular, GNU CC version 2 treats global 188: constant variables slightly differently from GNU CC version 1, 189: and GAS version 1.38.1 does not have the patches required to work 190: with GCC version 2. If you use GAS 1.38.1, then `extern const' 191: variables will not have the read-only bit set, and the linker 192: will generate warning messages about mismatched psect attributes 193: for these variables. These warning messages are merely a 194: nuisance, and can safely be ignored. 195: 196: If you are compiling with a version of GNU CC older than 1.33, 197: specify `/DEFINE=("inline=")' as an option in all the 198: compilations. This requires editing all the `gcc' commands in 199: `make-cc1.com'. (The older versions had problems supporting 200: `inline'.) Once you have a working 1.33 or newer GNU CC, you can 201: change this file back. 202: 203: Under previous versions of GNU CC, the generated code would 204: occasionally give strange results when linked to the sharable 205: `VAXCRTL' library. Now this should work. 206: 207: Even with this version, however, GNU CC itself should not be linked 208: to the sharable `VAXCRTL'. The `qsort' routine supplied with 209: `VAXCRTL' has a bug which can cause a compiler crash. 210: 211: Similarly, the preprocessor should not be linked to the sharable 212: `VAXCRTL'. The `strncat' routine supplied with `VAXCRTL' has a bug 213: which can cause the preprocessor to go into an infinite loop. 214: 215: If you attempt to link to the sharable `VAXCRTL', the VMS linker 216: will strongly resist any effort to force it to use the `qsort' and 217: `strncat' routines from `gcclib'. Until the bugs in `VAXCRTL' have 218: been fixed, linking any of the compiler components to the sharable 219: VAXCRTL is not recommended. (These routines can be bypassed by 220: placing duplicate copies of `qsort' and `strncat' in `gcclib' under 221: different names, and patching the compiler sources to use these 222: routines). Both of the bugs in `VAXCRTL' are still present in VMS 223: version 5.4-1, which is the most recent version as of this writing. 224: 225: The executables that are generated by `make-cc1.com' and 226: `make-cccp.com' use the nonshared version of `VAXCRTL' (and thus use 227: the `qsort' and `strncat' routines from `gcclib.olb'). 228: 229: 230: File: gcc.info, Node: Trouble, Next: Service, Prev: Installation, Up: Top 231: 232: Known Causes of Trouble with GNU CC 233: *********************************** 234: 235: Here are some of the things that have caused trouble for people 236: installing or using GNU CC. 237: 238: * On certain systems, defining certain environment variables such as 239: `CC' can interfere with the functioning of `make'. 240: 1.1.1.2 ! root 241: * If you encounter seemingly strange errors when trying to build the ! 242: compiler in a directory other than the source directory, make ! 243: sure you have done all the necessary preparations. *Note Other ! 244: Dir::. ! 245: ! 246: * In previous versions of GNU CC, the `gcc' driver program looked ! 247: for `as' and `ld' in various places such as files beginning with ! 248: `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in the ! 249: directory `/usr/local/lib/gcc/TARGET/VERSION'. ! 250: ! 251: Thus, to use a version of `as' or `ld' that is not the system ! 252: default, for example `gas' or GNU `ld', you must put them in that ! 253: directory (or make links to them from that directory). ! 254: ! 255: * Some commands executed when making the compiler may fail (return a ! 256: non-zero status) and be ignored by `make'. These failes, which ! 257: are often due to files that were not found, are expected, and can ! 258: safely be ignored. ! 259: 1.1 root 260: * Cross compilation can run into trouble for certain machines 261: because some target machines' assemblers require floating point 262: numbers to be written as *integer* constants in certain contexts. 263: 264: The compiler writes these integer constants by examining the 265: floating point value as an integer and printing that integer, 266: because this is simple to write and independent of the details of 267: the floating point representation. But this does not work if the 268: compiler is running on a different machine with an incompatible 269: floating point format, or even a different byte-ordering. 270: 271: In addition, correct constant folding of floating point values 272: requires representing them in the target machine's format. (The 273: C standard does not quite require this, but in practice it is the 274: only way to win.) 275: 276: It is now possible to overcome these problems by defining macros 277: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount 278: of work for each target machine. *Note Cross-compilation::. 279: 280: * Users often think it is a bug when GNU CC reports an error for 281: code like this: 282: 283: int foo (short); 284: 285: int foo (x) 286: short x; 287: {...} 288: 289: The error message is correct: this code really is erroneous, 290: because the old-style non-prototype definition passes subword 291: integers in their promoted types. In other words, the argument 292: is really an `int', not a `short'. The correct prototype is this: 293: 294: int foo (int); 295: 296: * Users often think it is a bug when GNU CC reports an error for 297: code like this: 298: 299: int foo (struct mumble *); 300: 301: struct mumble { ... }; 302: 303: int foo (struct mumble *x) 304: { ... } 305: 306: This code really is erroneous, because the scope of `struct 307: mumble' the prototype is limited to the argument list containing 308: it. It does not refer to the `struct mumble' defined with file 309: scope immediately below--they are two unrelated types with 310: similar names in different scopes. 311: 312: But in the definition of `foo', the file-scope type is used 313: because that is available to be inherited. Thus, the definition 314: and the prototype do not match, and you get an error. 315: 316: This behavior may seem silly, but it's what the ANSI standard 317: specifies. It is easy enough for you to make your code work by 318: moving the definition of `struct mumble' above the prototype. 319: It's not worth being incompatible with ANSI C just to avoid an 320: error for the example shown above. 321: 1.1.1.2 ! root 322: * Programs that use preprocessor directives in the middle of macro ! 323: arguments do not work with GNU CC. For example, a program like ! 324: this will not work: ! 325: ! 326: foobar ( ! 327: #define luser ! 328: hack) ! 329: ! 330: ANSI C does not permit such a construct, and it does not seem ! 331: worth the trouble of implementing, given that it is not required. ! 332: 1.1 root 333: * Certain local variables aren't recognized by debuggers when you 334: compile with optimization. 335: 336: This occurs because sometimes GNU CC optimizes the variable out of 337: existence. There is no way to tell the debugger how to compute 338: the value such a variable "would have had", and it is not clear 339: that would be desirable anyway. So GNU CC simply does not 340: mention the eliminated variable when it writes debugging 341: information. 342: 343: You have to expect a certain amount of disagreement between the 344: executable and your source code, when you use optimization. 345: 346: * `-2147483648' is positive. 347: 348: This is because 2147483648 cannot fit in the type `int', so 349: (following the ANSI C rules) its data type is `unsigned long int'. 350: Negating this value yields 2147483648 again. 351: 1.1.1.2 ! root 352: * The GNU assembler (GAS) does not support PIC. To generate PIC ! 353: code, you must use some other assembler, such as `/bin/as'. ! 354: 1.1 root 355: * Sometimes on a Sun 4 you may observe a crash in the program 1.1.1.2 ! root 356: `genflags' or `genoutput' while building GCC. This is said to be ! 357: due to a bug in `sh'. You can probably get around it by running ! 358: `genflags' or `genoutput' manually and then retrying the `make'. ! 359: ! 360: * On a Sun, linking using GNU CC fails to find a shared library and ! 361: reports that the library doesn't exist at all. ! 362: ! 363: This happens if you are using the GNU linker, because it does only ! 364: static linking and looks only for unshared libraries. If you ! 365: have a shared library with no unshared counterpart, the GNU ! 366: linker won't find anything. ! 367: ! 368: We hope to make a linker which supports Sun shared libraries, but ! 369: please don't ask when it will be finished--we don't know. 1.1 root 370: 371: * On some versions of Ultrix, the system supplied compiler cannot 372: compile `cp-parse.c' because it cannot handle so many cases in a 373: `switch' statement. You can work around this problem by 374: compiling with GNU CC. 375: 376: * On some BSD systems including some versions of Ultrix, use of 377: profiling causes static variable destructors (currently used only 378: in C++) not to be run. 379: 1.1.1.2 ! root 380: * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is ! 381: a bug in the assembler that must be fixed before GNU CC can be ! 382: built. This bug manifests itself during the first stage of ! 383: compilation, while building `libgcc2.a': ! 384: ! 385: _floatdisf ! 386: cc1: warning: `-g' option not supported on this version of GCC ! 387: cc1: warning: `-g1' option not supported on this version of GCC ! 388: ./gcc: Internal compiler error: program as got fatal signal 11 ! 389: ! 390: A patched version of the assembler is available by anonymous ftp ! 391: from `altdorf.ai.mit.edu' as the file ! 392: `archive/cph/hpux-8.0-assembler'. If you have HP software ! 393: support, the patch can also be obtained directly from HP, as ! 394: described in the following note: ! 395: ! 396: This is the patched assembler, to patch SR#1653-010439, ! 397: where the assembler aborts on floating point constants. ! 398: ! 399: The bug is not really in the assembler, but in the shared ! 400: library version of the function "cvtnum(3c)". The bug on ! 401: "cvtnum(3c)" is SR#4701-078451. Anyway, the attached ! 402: assembler uses the archive library version of "cvtnum(3c)" ! 403: and thus does not exhibit the bug. ! 404: ! 405: This patch is also known as PHCO_0800. ! 406: ! 407: * The current version of the assembler (`/bin/as') for the RS/6000 ! 408: has certain problems that prevent the `-g' option in GCC from ! 409: working. ! 410: ! 411: IBM has produced a fixed version of the assembler. The ! 412: replacement assembler is not a standard component of either AIX ! 413: 3.1.5 or AIX 3.2, but is expected to become standard in a future ! 414: distribution. This assembler is available from IBM as APAR ! 415: IX22829. See the file `README.RS6000' for more details on how to ! 416: obtain this assembler. ! 417: ! 418: * Sun forgot to include a static version of `libdl.a' with some ! 419: versions of SunOS (mainly 4.1). This results in undefined ! 420: symbols when linking static binaries (that is, if you use ! 421: `-static'). If you see undefined symbols `_dlclose', `_dlsym' or ! 422: `_dlopen' when linking, compile and link against the file ! 423: `mit/util/misc/dlsym.c' from the MIT version of X windows. ! 424: 1.1 root 425: * On the IBM RS/6000, compiling code of the form 426: 427: extern int foo; 428: 429: ... foo ... 430: 431: static int foo; 432: 433: will cause the linker to report an undefined symbol `foo'. 434: Although this behavior differs from most other systems, it is not 435: a bug because redefining an `extern' variable as `static' is 436: undefined in ANSI C. 437: 1.1.1.2 ! root 438: * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning ! 439: messages from the linker. These warning messages complain of ! 440: mismatched psect attributes. You can ignore them. *Note VMS ! 441: Install::. ! 442: 1.1 root 443: For additional common problems, see *Note Incompatibilities::. 444: 445: 446: File: gcc.info, Node: Service, Next: Incompatibilities, Prev: Trouble, Up: Top 447: 448: How To Get Help with GNU CC 449: *************************** 450: 451: If you need help installing, using or changing GNU CC, there are two 452: ways to find it: 453: 454: * Send a message to a suitable network mailing list. First try 455: `[email protected]', and if that brings no response, try 456: `[email protected]'. 457: 458: * Look in the service directory for someone who might help you for 459: a fee. The service directory is found in the file named 460: `SERVICE' in the GNU CC distribution. 461: 462: 463: File: gcc.info, Node: Incompatibilities, Next: Extensions, Prev: Service, Up: Top 464: 465: Incompatibilities of GNU CC 466: *************************** 467: 468: There are several noteworthy incompatibilities between GNU C and 469: most existing (non-ANSI) versions of C. The `-traditional' option 470: eliminates most of these incompatibilities, *but not all*, by telling 471: GNU C to behave like the other C compilers. 472: 473: * GNU CC normally makes string constants read-only. If several 474: identical-looking string constants are used, GNU CC stores only 475: one copy of the string. 476: 477: One consequence is that you cannot call `mktemp' with a string 478: constant argument. The function `mktemp' always alters the 479: string its argument points to. 480: 481: Another consequence is that `sscanf' does not work on some systems 482: when passed a string constant as its format control string or 483: input. This is because `sscanf' incorrectly tries to write into 484: the string constant. Likewise `fscanf' and `scanf'. 485: 486: The best solution to these problems is to change the program to 487: use `char'-array variables with initialization strings for these 488: purposes instead of string constants. But if this is not 489: possible, you can use the `-fwritable-strings' flag, which 490: directs GNU CC to handle string constants the same way most C 491: compilers do. `-traditional' also has this effect, among others. 492: 493: * GNU CC does not substitute macro arguments when they appear 494: inside of string constants. For example, the following macro in 495: GNU CC 496: 497: #define foo(a) "a" 498: 499: will produce output `"a"' regardless of what the argument A is. 500: 501: The `-traditional' option directs GNU CC to handle such cases 502: (among others) in the old-fashioned (non-ANSI) fashion. 503: 504: * When you use `setjmp' and `longjmp', the only automatic variables 505: guaranteed to remain valid are those declared `volatile'. This 506: is a consequence of automatic register allocation. Consider this 507: function: 508: 509: jmp_buf j; 510: 511: foo () 512: { 513: int a, b; 514: 515: a = fun1 (); 516: if (setjmp (j)) 517: return a; 518: 519: a = fun2 (); 520: /* `longjmp (j)' may occur in `fun3'. */ 521: return a + fun3 (); 522: } 523: 524: Here `a' may or may not be restored to its first value when the 525: `longjmp' occurs. If `a' is allocated in a register, then its 526: first value is restored; otherwise, it keeps the last value stored 527: in it. 528: 529: If you use the `-W' option with the `-O' option, you will get a 530: warning when GNU CC thinks such a problem might be possible. 531: 532: The `-traditional' option directs GNU C to put variables in the 533: stack by default, rather than in registers, in functions that 534: call `setjmp'. This results in the behavior found in traditional 535: C compilers. 536: 537: * Declarations of external variables and functions within a block 538: apply only to the block containing the declaration. In other 539: words, they have the same scope as any other declaration in the 540: same place. 541: 542: In some other C compilers, a `extern' declaration affects all the 543: rest of the file even if it happens within a block. 544: 545: The `-traditional' option directs GNU C to treat all `extern' 546: declarations as global, like traditional compilers. 547: 548: * In traditional C, you can combine `long', etc., with a typedef 549: name, as shown here: 550: 551: typedef int foo; 552: typedef long foo bar; 553: 554: In ANSI C, this is not allowed: `long' and other type modifiers 555: require an explicit `int'. Because this criterion is expressed 556: by Bison grammar rules rather than C code, the `-traditional' 557: flag cannot alter it. 558: 559: * PCC allows typedef names to be used as function parameters. The 560: difficulty described immediately above applies here too. 561: 562: * PCC allows whitespace in the middle of compound assignment 563: operators such as `+='. GNU CC, following the ANSI standard, 564: does not allow this. The difficulty described immediately above 565: applies here too. 566: 567: * GNU CC will flag unterminated character constants inside of 568: preprocessor conditionals that fail. Some programs have English 569: comments enclosed in conditionals that are guaranteed to fail; if 570: these comments contain apostrophes, GNU CC will probably report 571: an error. For example, this code would produce an error: 572: 573: #if 0 574: You can't expect this to work. 575: #endif 576: 577: The best solution to such a problem is to put the text into an 578: actual C comment delimited by `/*...*/'. However, `-traditional' 579: suppresses these error messages. 580: 581: * When compiling functions that return `float', PCC converts it to 582: a double. GNU CC actually returns a `float'. If you are 583: concerned with PCC compatibility, you should declare your 584: functions to return `double'; you might as well say what you mean. 585: 586: * When compiling functions that return structures or unions, GNU CC 587: output code normally uses a method different from that used on 588: most versions of Unix. As a result, code compiled with GNU CC 589: cannot call a structure-returning function compiled with PCC, and 590: vice versa. 591: 592: The method used by GNU CC is as follows: a structure or union 593: which is 1, 2, 4 or 8 bytes long is returned like a scalar. A 594: structure or union with any other size is stored into an address 595: supplied by the caller (usually in a special, fixed register, but 596: on some machines it is passed on the stack). The 597: machine-description macros `STRUCT_VALUE' and 598: `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. 599: 600: By contrast, PCC on most target machines returns structures and 601: unions of any size by copying the data into an area of static 602: storage, and then returning the address of that storage as if it 603: were a pointer value. The caller must copy the data from that 604: memory area to the place where the value is wanted. GNU CC does 605: not use this method because it is slower and nonreentrant. 606: 607: On some newer machines, PCC uses a reentrant convention for all 608: structure and union returning. GNU CC on most of these machines 609: uses a compatible convention when returning structures and unions 610: in memory, but still returns small structures and unions in 611: registers. 612: 613: You can tell GNU CC to use a compatible convention for all 614: structure and union returning with the option 615: `-fpcc-struct-return'. 616: 617: There are also system-specific incompatibilities. 618: 619: * On the Alliant, the system's own convention for returning 620: structures and unions is unusual, and is not compatible with GNU 621: CC no matter what options are used. 622: 623: * On the IBM RT PC, the MetaWare HighC compiler (hc) uses yet 624: another convention for structure and union returning. Use 625: `-mhc-struct-return' to tell GNU CC to use a convention compatible 626: with it. 627: 628: * On Ultrix, the Fortran compiler expects registers 2 through 5 to 629: be saved by function calls. However, the C compiler uses 630: conventions compatible with BSD Unix: registers 2 through 5 may 631: be clobbered by function calls. 632: 633: GNU CC uses the same convention as the Ultrix C compiler. You 634: can use these options to produce code compatible with the Fortran 635: compiler: 636: 637: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 638: 639: * DBX rejects some files produced by GNU CC, though it accepts 640: similar constructs in output from PCC. Until someone can supply 641: a coherent description of what is valid DBX input and what is 642: not, there is nothing I can do about these problems. You are on 643: your own. 644: 645: 646: File: gcc.info, Node: Extensions, Next: Bugs, Prev: Incompatibilities, Up: Top 647: 648: GNU Extensions to the C Language 649: ******************************** 650: 651: GNU C provides several language features not found in ANSI standard 652: C. (The `-pedantic' option directs GNU CC to print a warning message 653: if any of these features is used.) To test for the availability of 654: these features in conditional compilation, check for a predefined macro 655: `__GNUC__', which is always defined under GNU CC. 656: 657: * Menu: 658: 659: * Statement Exprs:: Putting statements and declarations inside expressions. 660: * Local Labels:: Labels local to a statement-expression. 661: * Labels as Values:: Getting pointers to labels, and computed gotos. 662: * Nested Functions:: As in Algol and Pascal, lexical scoping of functions. 663: * Naming Types:: Giving a name to the type of some expression. 664: * Typeof:: `typeof': referring to the type of an expression. 665: * Lvalues:: Using `?:', `,' and casts in lvalues. 666: * Conditionals:: Omitting the middle operand of a `?:' expression. 667: * Long Long:: Double-word integers--`long long int'. 668: * Zero Length:: Zero-length arrays. 669: * Variable Length:: Arrays whose length is computed at run time. 670: * Subscripting:: Any array can be subscripted, even if not an lvalue. 671: * Pointer Arith:: Arithmetic on `void'-pointers and function pointers. 672: * Initializers:: Non-constant initializers. 673: * Constructors:: Constructor expressions give structures, unions 674: or arrays as values. 675: * Labeled Elements:: Labeling elements of initializers. 676: * Cast to Union:: Casting to union type from any member of the union. 677: * Case Ranges:: `case 1 ... 9' and such. 678: * Function Attributes:: Declaring that functions have no side effects, 679: or that they can never return. 680: * Dollar Signs:: Dollar sign is allowed in identifiers. 681: * Character Escapes:: `\e' stands for the character ESC. 682: * Variable Attributes:: Specifying attributes of variables. 683: * Alignment:: Inquiring about the alignment of a type or variable. 684: * Inline:: Defining inline functions (as fast as macros). 685: * Extended Asm:: Assembler instructions with C expressions as operands. 686: (With them you can define "built-in" functions.) 687: * Asm Labels:: Specifying the assembler name to use for a C symbol. 688: * Explicit Reg Vars:: Defining variables residing in specified registers. 689: * Alternate Keywords:: `__const__', `__asm__', etc., for header files. 690: * Incomplete Enums:: `enum foo;', with details to follow. 691: 692: 693: File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: Extensions 694: 695: Statements and Declarations within Expressions 696: ============================================== 697: 698: A compound statement in parentheses may appear inside an expression 699: in GNU C. This allows you to declare variables within an expression. 700: For example: 701: 702: ({ int y = foo (); int z; 703: if (y > 0) z = y; 704: else z = - y; 705: z; }) 706: 707: is a valid (though slightly more complex than necessary) expression 708: for the absolute value of `foo ()'. 709: 710: This feature is especially useful in making macro definitions 711: "safe" (so that they evaluate each operand exactly once). For 712: example, the "maximum" function is commonly defined as a macro in 713: standard C as follows: 714: 715: #define max(a,b) ((a) > (b) ? (a) : (b)) 716: 717: But this definition computes either A or B twice, with bad results if 718: the operand has side effects. In GNU C, if you know the type of the 719: operands (here let's assume `int'), you can define the macro safely as 720: follows: 721: 722: #define maxint(a,b) \ 723: ({int _a = (a), _b = (b); _a > _b ? _a : _b; }) 724: 725: Embedded statements are not allowed in constant expressions, such as 726: the value of an enumeration constant, the width of a bit field, or the 727: initial value of a static variable. 728: 729: If you don't know the type of the operand, you can still do this, 730: but you must use `typeof' (*note Typeof::.) or type naming (*note 731: Naming Types::.). 732: 733: 734: File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: Extensions 735: 736: Locally Declared Labels 737: ======================= 738: 739: Each statement expression is a scope in which "local labels" can be 740: declared. A local label is simply an identifier; you can jump to it 741: with an ordinary `goto' statement, but only from within the statement 742: expression it belongs to. 743: 744: A local label declaration looks like this: 745: 746: __label__ LABEL; 747: 748: or 749: 750: __label__ LABEL1, LABEL2, ...; 751: 752: Local label declarations must come at the beginning of the statement 753: expression, right after the `({', before any ordinary declarations. 754: 755: The label declaration defines the label *name*, but does not define 756: the label itself. You must do this in the usual way, with `LABEL:', 757: within the statements of the statement expression. 758: 759: The local label feature is useful because statement expressions are 760: often used in macros. If the macro contains nested loops, a `goto' 761: can be useful for breaking out of them. However, an ordinary label 762: whose scope is the whole function cannot be used: if the macro can be 763: expanded several times in one function, the label will be multiply 764: defined in that function. A local label avoids this problem. For 765: example: 766: 767: #define SEARCH(array, target) \ 768: ({ \ 769: __label__ found; \ 770: typeof (target) _SEARCH_target = (target); \ 771: typeof (*(array)) *_SEARCH_array = (array); \ 772: int i, j; \ 773: int value; \ 774: for (i = 0; i < max; i++) \ 775: for (j = 0; j < max; j++) \ 776: if (_SEARCH_array[i][j] == _SEARCH_target) \ 777: { value = i; goto found; } \ 778: value = -1; \ 779: found: \ 780: value; \ 781: }) 782: 783: 784: File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: Extensions 785: 786: Labels as Values 787: ================ 788: 789: You can get the address of a label defined in the current function 790: (or a containing function) with the unary operator `&&'. The value 791: has type `void *'. This value is a constant and can be used wherever 792: a constant of that type is valid. For example: 793: 794: void *ptr; 795: ... 796: ptr = &&foo; 797: 798: To use these values, you need to be able to jump to one. This is 799: done with the computed goto statement(1), `goto *EXP;'. For example, 800: 801: goto *ptr; 802: 803: Any expression of type `void *' is allowed. 804: 805: One way of using these constants is in initializing a static array 806: that will serve as a jump table: 807: 808: static void *array[] = { &&foo, &&bar, &&hack }; 809: 810: Then you can select a label with indexing, like this: 811: 812: goto *array[i]; 813: 814: Note that this does not check whether the subscript is in bounds--array 815: indexing in C never does that. 816: 817: Such an array of label values serves a purpose much like that of the 818: `switch' statement. The `switch' statement is cleaner, so use that 819: rather than an array unless the problem does not fit a `switch' 820: statement very well. 821: 822: Another use of label values is in an interpreter for threaded code. 823: The labels within the interpreter function can be stored in the 824: threaded code for super-fast dispatching. 825: 826: ---------- Footnotes ---------- 827: 828: (1) The analogous feature in Fortran is called an assigned goto, 829: but that name seems inappropriate in C, where one can do more than 830: simply store label addresses in label variables. 831: 832: 833: File: gcc.info, Node: Nested Functions, Next: Naming Types, Prev: Labels as Values, Up: Extensions 834: 835: Nested Functions 836: ================ 837: 838: A "nested function" is a function defined inside another function. 839: The nested function's name is local to the block where it is defined. 840: For example, here we define a nested function named `square', and call 841: it twice: 842: 843: foo (double a, double b) 844: { 845: double square (double z) { return z * z; } 846: 847: return square (a) + square (b); 848: } 849: 850: The nested function can access all the variables of the containing 851: function that are visible at the point of its definition. This is 852: called "lexical scoping". For example, here we show a nested function 853: which uses an inherited variable named `offset': 854: 855: bar (int *array, int offset, int size) 856: { 857: int access (int *array, int index) 858: { return array[index + offset]; } 859: int i; 860: ... 861: for (i = 0; i < size; i++) 862: ... access (array, i) ... 863: } 864: 865: It is possible to call the nested function from outside the scope 866: of its name by storing its address or passing the address to another 867: function: 868: 869: hack (int *array, int size) 870: { 871: void store (int index, int value) 872: { array[index] = value; } 873: 874: intermediate (store, size); 875: } 876: 877: Here, the function `intermediate' receives the address of `store' 878: as an argument. If `intermediate' calls `store', the arguments given 879: to `store' are used to store into `array'. But this technique works 880: only so long as the containing function (`hack', in this example) does 881: not exit. If you try to call the nested function through its address 882: after the containing function has exited, all hell will break loose. 883: 884: A nested function can jump to a label inherited from a containing 885: function, provided the label was explicitly declared in the containing 886: function (*note Local Labels::.). Such a jump returns instantly to the 887: containing function, exiting the nested function which did the `goto' 888: and any intermediate functions as well. Here is an example: 889: 890: bar (int *array, int offset, int size) 891: { 892: __label__ failure; 893: int access (int *array, int index) 894: { 895: if (index > size) 896: goto failure; 897: return array[index + offset]; 898: } 899: int i; 900: ... 901: for (i = 0; i < size; i++) 902: ... access (array, i) ... 903: ... 904: return 0; 905: 906: /* Control comes here from `access' 907: if it detects an error. */ 908: failure: 909: return -1; 910: } 911: 912: A nested function always has internal linkage. Declaring one with 913: `extern' is erroneous. If you need to declare the nested function 914: before its definition, use `auto' (which is otherwise meaningless for 915: function declarations). 916: 917: bar (int *array, int offset, int size) 918: { 919: __label__ failure; 920: auto int access (int *, int); 921: ... 922: int access (int *array, int index) 923: { 924: if (index > size) 925: goto failure; 926: return array[index + offset]; 927: } 928: ... 929: } 930: 931: 932: File: gcc.info, Node: Naming Types, Next: Typeof, Prev: Nested Functions, Up: Extensions 933: 934: Naming an Expression's Type 935: =========================== 936: 937: You can give a name to the type of an expression using a `typedef' 938: declaration with an initializer. Here is how to define NAME as a type 939: name for the type of EXP: 940: 941: typedef NAME = EXP; 942: 943: This is useful in conjunction with the statements-within-expressions 944: feature. Here is how the two together can be used to define a safe 945: "maximum" macro that operates on any arithmetic type: 946: 947: #define max(a,b) \ 948: ({typedef _ta = (a), _tb = (b); \ 949: _ta _a = (a); _tb _b = (b); \ 950: _a > _b ? _a : _b; }) 951: 952: The reason for using names that start with underscores for the local 953: variables is to avoid conflicts with variable names that occur within 954: the expressions that are substituted for `a' and `b'. Eventually we 955: hope to design a new form of declaration syntax that allows you to 956: declare variables whose scopes start only after their initializers; 957: this will be a more reliable way to prevent such conflicts. 958: 959: 960: File: gcc.info, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: Extensions 961: 962: Referring to a Type with `typeof' 963: ================================= 964: 965: Another way to refer to the type of an expression is with `typeof'. 966: The syntax of using of this keyword looks like `sizeof', but the 967: construct acts semantically like a type name defined with `typedef'. 968: 969: There are two ways of writing the argument to `typeof': with an 970: expression or with a type. Here is an example with an expression: 971: 972: typeof (x[0](1)) 973: 974: This assumes that `x' is an array of functions; the type described is 975: that of the values of the functions. 976: 977: Here is an example with a typename as the argument: 978: 979: typeof (int *) 980: 981: Here the type described is that of pointers to `int'. 982: 983: If you are writing a header file that must work when included in 984: ANSI C programs, write `__typeof__' instead of `typeof'. *Note 985: Alternate Keywords::. 986: 987: A `typeof'-construct can be used anywhere a typedef name could be 988: used. For example, you can use it in a declaration, in a cast, or 989: inside of `sizeof' or `typeof'. 990: 991: * This declares `y' with the type of what `x' points to. 992: 993: typeof (*x) y; 994: 995: * This declares `y' as an array of such values. 996: 997: typeof (*x) y[4]; 998: 999: * This declares `y' as an array of pointers to characters: 1000: 1001: typeof (typeof (char *)[4]) y; 1002: 1003: It is equivalent to the following traditional C declaration: 1004: 1005: char *y[4]; 1006: 1007: To see the meaning of the declaration using `typeof', and why it 1008: might be a useful way to write, let's rewrite it with these 1009: macros: 1010: 1011: #define pointer(T) typeof(T *) 1012: #define array(T, N) typeof(T [N]) 1013: 1014: Now the declaration can be rewritten this way: 1015: 1016: array (pointer (char), 4) y; 1017: 1018: Thus, `array (pointer (char), 4)' is the type of arrays of 4 1019: pointers to `char'. 1020: 1021: 1022: File: gcc.info, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: Extensions 1023: 1024: Generalized Lvalues 1025: =================== 1026: 1027: Compound expressions, conditional expressions and casts are allowed 1028: as lvalues provided their operands are lvalues. This means that you 1029: can take their addresses or store values into them. 1030: 1031: For example, a compound expression can be assigned, provided the 1032: last expression in the sequence is an lvalue. These two expressions 1033: are equivalent: 1034: 1035: (a, b) += 5 1036: a, (b += 5) 1037: 1038: Similarly, the address of the compound expression can be taken. 1039: These two expressions are equivalent: 1040: 1041: &(a, b) 1042: a, &b 1043: 1044: A conditional expression is a valid lvalue if its type is not void 1045: and the true and false branches are both valid lvalues. For example, 1046: these two expressions are equivalent: 1047: 1048: (a ? b : c) = 5 1049: (a ? b = 5 : (c = 5)) 1050: 1051: A cast is a valid lvalue if its operand is an lvalue. A simple 1052: assignment whose left-hand side is a cast works by converting the 1053: right-hand side first to the specified type, then to the type of the 1054: inner left-hand side expression. After this is stored, the value is 1055: converted back to the specified type to become the value of the 1056: assignment. Thus, if `a' has type `char *', the following two 1057: expressions are equivalent: 1058: 1059: (int)a = 5 1060: (int)(a = (char *)(int)5) 1061: 1062: An assignment-with-arithmetic operation such as `+=' applied to a 1063: cast performs the arithmetic using the type resulting from the cast, 1064: and then continues as in the previous case. Therefore, these two 1065: expressions are equivalent: 1066: 1067: (int)a += 5 1068: (int)(a = (char *)(int) ((int)a + 5)) 1069: 1070: You cannot take the address of an lvalue cast, because the use of 1071: its address would not work out coherently. Suppose that `&(int)f' were 1072: permitted, where `f' has type `float'. Then the following statement 1073: would try to store an integer bit-pattern where a floating point 1074: number belongs: 1075: 1076: *&(int)f = 1; 1077: 1078: This is quite different from what `(int)f = 1' would do--that would 1079: convert 1 to floating point and store it. Rather than cause this 1.1.1.2 ! root 1080: inconsistency, we think it is better to prohibit use of `&' on a cast. 1.1 root 1081: 1082: If you really do want an `int *' pointer with the address of `f', 1083: you can simply write `(int *)&f'. 1084: 1085: 1086: File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Lvalues, Up: Extensions 1087: 1088: Conditional Expressions with Omitted Operands 1089: ============================================= 1090: 1091: The middle operand in a conditional expression may be omitted. Then 1092: if the first operand is nonzero, its value is the value of the 1093: conditional expression. 1094: 1095: Therefore, the expression 1096: 1097: x ? : y 1098: 1099: has the value of `x' if that is nonzero; otherwise, the value of `y'. 1100: 1101: This example is perfectly equivalent to 1102: 1103: x ? x : y 1104: 1105: In this simple case, the ability to omit the middle operand is not 1106: especially useful. When it becomes useful is when the first operand 1107: does, or may (if it is a macro argument), contain a side effect. Then 1108: repeating the operand in the middle would perform the side effect 1109: twice. Omitting the middle operand uses the value already computed 1110: without the undesirable effects of recomputing it. 1111: 1112: 1113: File: gcc.info, Node: Long Long, Next: Zero Length, Prev: Conditionals, Up: Extensions 1114: 1115: Double-Word Integers 1116: ==================== 1117: 1118: GNU C supports data types for integers that are twice as long as 1119: `long int'. Simply write `long long int' for a signed integer, or 1120: `unsigned long long int' for an unsigned integer. 1121: 1122: You can use these types in arithmetic like any other integer types. 1123: Addition, subtraction, and bitwise boolean operations on these types 1124: are open-coded on all types of machines. Multiplication is open-coded 1125: if the machine supports fullword-to-doubleword a widening multiply 1126: instruction. Division and shifts are open-coded only on machines that 1127: provide special support. The operations that are not open-coded use 1128: special library routines that come with GNU CC. 1129: 1130: There may be pitfalls when you use `long long' types for function 1131: arguments, unless you declare function prototypes. If a function 1132: expects type `int' for its argument, and you pass a value of type 1133: `long long int', confusion will result because the caller and the 1134: subroutine will disagree about the number of bytes for the argument. 1135: Likewise, if the function expects `long long int' and you pass `int'. 1136: The best way to avoid such problems is to use prototypes. 1137: 1138: 1139: File: gcc.info, Node: Zero Length, Next: Variable Length, Prev: Long Long, Up: Extensions 1140: 1141: Arrays of Length Zero 1142: ===================== 1143: 1144: Zero-length arrays are allowed in GNU C. They are very useful as 1145: the last element of a structure which is really a header for a 1146: variable-length object: 1147: 1148: struct line { 1149: int length; 1150: char contents[0]; 1151: }; 1152: 1153: { 1154: struct line *thisline = (struct line *) 1155: malloc (sizeof (struct line) + this_length); 1156: thisline->length = this_length; 1157: } 1158: 1159: In standard C, you would have to give `contents' a length of 1, 1160: which means either you waste space or complicate the argument to 1161: `malloc'. 1162: 1163: 1164: File: gcc.info, Node: Variable Length, Next: Subscripting, Prev: Zero Length, Up: Extensions 1165: 1166: Arrays of Variable Length 1167: ========================= 1168: 1169: Variable-length automatic arrays are allowed in GNU C. These 1170: arrays are declared like any other automatic arrays, but with a length 1171: that is not a constant expression. The storage is allocated at the 1172: point of declaration and deallocated when the brace-level is exited. 1173: For example: 1174: 1175: FILE * 1176: concat_fopen (char *s1, char *s2, char *mode) 1177: { 1178: char str[strlen (s1) + strlen (s2) + 1]; 1179: strcpy (str, s1); 1180: strcat (str, s2); 1181: return fopen (str, mode); 1182: } 1183: 1184: Jumping or breaking out of the scope of the array name deallocates 1185: the storage. Jumping into the scope is not allowed; you get an error 1186: message for it. 1187: 1188: You can use the function `alloca' to get an effect much like 1189: variable-length arrays. The function `alloca' is available in many 1190: other C implementations (but not in all). On the other hand, 1191: variable-length arrays are more elegant. 1192: 1193: There are other differences between these two methods. Space 1194: allocated with `alloca' exists until the containing *function* returns. 1195: The space for a variable-length array is deallocated as soon as the 1196: array name's scope ends. (If you use both variable-length arrays and 1197: `alloca' in the same function, deallocation of a variable-length array 1198: will also deallocate anything more recently allocated with `alloca'.) 1199: 1200: You can also use variable-length arrays as arguments to functions: 1201: 1202: struct entry 1203: tester (int len, char data[len][len]) 1204: { 1205: ... 1206: } 1207: 1208: The length of an array is computed once when the storage is 1209: allocated and is remembered for the scope of the array in case you 1210: access it with `sizeof'. 1211: 1212: If you want to pass the array first and the length afterward, you 1213: can use a forward declaration in the parameter list--another GNU 1214: extension. 1215: 1216: struct entry 1217: tester (int len; char data[len][len], int len) 1218: { 1219: ... 1220: } 1221: 1222: The `int len' before the semicolon is a "parameter forward 1223: declaration", and it serves the purpose of making the name `len' known 1224: when the declaration of `data' is parsed. 1225: 1226: You can write any number of such parameter forward declarations in 1227: the parameter list. They can be separated by commas or semicolons, 1228: but the last one must end with a semicolon, which is followed by the 1229: "real" parameter declarations. Each forward declaration must match a 1230: "real" declaration in parameter name and data type. 1231: 1232: 1233: File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Variable Length, Up: Extensions 1234: 1235: Non-Lvalue Arrays May Have Subscripts 1236: ===================================== 1237: 1238: Subscripting is allowed on arrays that are not lvalues, even though 1239: the unary `&' operator is not. For example, this is valid in GNU C 1240: though not valid in other C dialects: 1241: 1242: struct foo {int a[4];}; 1243: 1244: struct foo f(); 1245: 1246: bar (int index) 1247: { 1248: return f().a[index]; 1249: } 1250: 1251: 1252: File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: Extensions 1253: 1254: Arithmetic on `void'- and Function-Pointers 1255: =========================================== 1256: 1257: In GNU C, addition and subtraction operations are supported on 1258: pointers to `void' and on pointers to functions. This is done by 1259: treating the size of a `void' or of a function as 1. 1260: 1261: A consequence of this is that `sizeof' is also allowed on `void' 1262: and on function types, and returns 1. 1263: 1264: The option `-Wpointer-arith' requests a warning if these extensions 1265: are used. 1266: 1267: 1268: File: gcc.info, Node: Initializers, Next: Constructors, Prev: Pointer Arith, Up: Extensions 1269: 1270: Non-Constant Initializers 1271: ========================= 1272: 1273: The elements of an aggregate initializer for an automatic variable 1274: are not required to be constant expressions in GNU C. Here is an 1275: example of an initializer with run-time varying elements: 1276: 1277: foo (float f, float g) 1278: { 1279: float beat_freqs[2] = { f-g, f+g }; 1280: ... 1281: } 1282: 1283:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.