![[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.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. 29: 30: 1.1.1.5 ! root 31: File: gcc.info, Node: DEC Alpha Options, Next: System V Options, Prev: Intel 960 Options, Up: Submodel Options ! 32: ! 33: DEC Alpha Options ! 34: ----------------- ! 35: ! 36: These `-m' options are defined for the DEC Alpha implementations: ! 37: ! 38: `-mno-soft-float' ! 39: `-msoft-float' ! 40: Use (do not use) the hardware floating-point instructions for ! 41: floating-point operations. When `-msoft-float' is specified, ! 42: functions in `libgcc1.c' will be used to perform floating-point ! 43: operations. Unless they are replaced by routines that emulate the ! 44: floating-point operations, or compiled in such a way as to call ! 45: such emulations routines, these routines will issue floating-point ! 46: operations. If you are compiling for an Alpha without ! 47: floating-point operations, you must ensure that the library is ! 48: built so as not to call them. ! 49: ! 50: Note that Alpha implementations without floating-point operations ! 51: are required to have floating-point registers. ! 52: ! 53: `-mfp-reg' ! 54: `-mno-fp-regs' ! 55: Generate code that uses (does not use) the floating-point register ! 56: set. `-mno-fp-regs' implies `-msoft-float'. If the floating-point ! 57: register set is not used, floating point operands are passed in ! 58: integer registers as if they were integers and floating-point ! 59: results are passed in $0 instead of $f0. This is a non-standard ! 60: calling sequence, so any function with a floating-point argument ! 61: or return value called by code compiled with `-mno-fp-regs' must ! 62: also be compiled with that option. ! 63: ! 64: A typical use of this option is building a kernel that does not ! 65: use, and hence need not save and restore, any floating-point ! 66: registers. ! 67: ! 68: ! 69: File: gcc.info, Node: System V Options, Prev: DEC Alpha Options, Up: Submodel Options ! 70: ! 71: Options for System V ! 72: -------------------- ! 73: ! 74: These additional options are available on System V Release 4 for ! 75: compatibility with other compilers on those systems: ! 76: ! 77: `-Qy' ! 78: Identify the versions of each tool used by the compiler, in a ! 79: `.ident' assembler directive in the output. ! 80: ! 81: `-Qn' ! 82: Refrain from adding `.ident' directives to the output file (this is ! 83: the default). ! 84: ! 85: `-YP,DIRS' ! 86: Search the directories DIRS, and no others, for libraries ! 87: specified with `-l'. ! 88: ! 89: `-Ym,DIR' ! 90: Look in the directory DIR to find the M4 preprocessor. The ! 91: assembler uses this option. ! 92: ! 93: ! 94: File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC ! 95: ! 96: Options for Code Generation Conventions ! 97: ======================================= ! 98: ! 99: These machine-independent options control the interface conventions ! 100: used in code generation. ! 101: ! 102: Most of them have both positive and negative forms; the negative form ! 103: of `-ffoo' would be `-fno-foo'. In the table below, only one of the ! 104: forms is listed--the one which is not the default. You can figure out ! 105: the other form by either removing `no-' or adding it. ! 106: ! 107: `-fpcc-struct-return' ! 108: Return "short" `struct' and `union' values in memory like longer ! 109: ones, rather than in registers. This convention is less ! 110: efficient, but it has the advantage of allowing intercallability ! 111: between GNU CC-compiled files and files compiled with other ! 112: compilers. ! 113: ! 114: The precise convention for returning structures in memory depends ! 115: on the target configuration macros. ! 116: ! 117: Short structures and unions are those whose size and alignment ! 118: match that of some integer type. ! 119: ! 120: `-freg-struct-return' ! 121: Use the convention that `struct' and `union' values are returned ! 122: in registers when possible. This is more efficient for small ! 123: structures than `-fpcc-struct-return'. ! 124: ! 125: If you specify neither `-fpcc-struct-return' nor its contrary ! 126: `-freg-struct-return', GNU CC defaults to whichever convention is ! 127: standard for the target. If there is no standard convention, GNU ! 128: CC defaults to `-fpcc-struct-return', except on targets where GNU ! 129: CC is the principal compiler. In those cases, we can choose the ! 130: standard, and we chose the more efficient register return ! 131: alternative. ! 132: ! 133: `-fshort-enums' ! 134: Allocate to an `enum' type only as many bytes as it needs for the ! 135: declared range of possible values. Specifically, the `enum' type ! 136: will be equivalent to the smallest integer type which has enough ! 137: room. ! 138: ! 139: `-fshort-double' ! 140: Use the same size for `double' as for `float'. ! 141: ! 142: `-fshared-data' ! 143: Requests that the data and non-`const' variables of this ! 144: compilation be shared data rather than private data. The ! 145: distinction makes sense only on certain operating systems, where ! 146: shared data is shared between processes running the same program, ! 147: while private data exists in one copy per process. ! 148: ! 149: `-fno-common' ! 150: Allocate even uninitialized global variables in the bss section of ! 151: the object file, rather than generating them as common blocks. ! 152: This has the effect that if the same variable is declared (without ! 153: `extern') in two different compilations, you will get an error ! 154: when you link them. The only reason this might be useful is if ! 155: you wish to verify that the program will work on other systems ! 156: which always work this way. ! 157: ! 158: `-fno-ident' ! 159: Ignore the `#ident' directive. ! 160: ! 161: `-fno-gnu-linker' ! 162: Do not output global initializations (such as C++ constructors and ! 163: destructors) in the form used by the GNU linker (on systems where ! 164: the GNU linker is the standard method of handling them). Use this ! 165: option when you want to use a non-GNU linker, which also requires ! 166: using the `collect2' program to make sure the system linker ! 167: includes constructors and destructors. (`collect2' is included in ! 168: the GNU CC distribution.) For systems which *must* use ! 169: `collect2', the compiler driver `gcc' is configured to do this ! 170: automatically. ! 171: ! 172: `-finhibit-size-directive' ! 173: Don't output a `.size' assembler directive, or anything else that ! 174: would cause trouble if the function is split in the middle, and the ! 175: two halves are placed at locations far apart in memory. This ! 176: option is used when compiling `crtstuff.c'; you should not need to ! 177: use it for anything else. ! 178: ! 179: `-fverbose-asm' ! 180: Put extra commentary information in the generated assembly code to ! 181: make it more readable. This option is generally only of use to ! 182: those who actually need to read the generated assembly code ! 183: (perhaps while debugging the compiler itself). ! 184: ! 185: `-fvolatile' ! 186: Consider all memory references through pointers to be volatile. ! 187: ! 188: `-fvolatile-global' ! 189: Consider all memory references to extern and global data items to ! 190: be volatile. ! 191: ! 192: `-fpic' ! 193: Generate position-independent code (PIC) suitable for use in a ! 194: shared library, if supported for the target machine. Such code ! 195: accesses all constant addresses through a global offset table ! 196: (GOT). If the GOT size for the linked executable exceeds a ! 197: machine-specific maximum size, you get an error message from the ! 198: linker indicating that `-fpic' does not work; in that case, ! 199: recompile with `-fPIC' instead. (These maximums are 16k on the ! 200: m88k, 8k on the Sparc, and 32k on the m68k and RS/6000. The 386 ! 201: has no such limit.) ! 202: ! 203: Position-independent code requires special support, and therefore ! 204: works only on certain machines. For the 386, GNU CC supports PIC ! 205: for System V but not for the Sun 386i. Code generated for the IBM ! 206: RS/6000 is always position-independent. ! 207: ! 208: The GNU assembler does not fully support PIC. Currently, you must ! 209: use some other assembler in order for PIC to work. We would ! 210: welcome volunteers to upgrade GAS to handle this; the first part ! 211: of the job is to figure out what the assembler must do differently. ! 212: ! 213: `-fPIC' ! 214: If supported for the target machine, emit position-independent ! 215: code, suitable for dynamic linking and avoiding any limit on the ! 216: size of the global offset table. This option makes a difference ! 217: on the m68k, m88k and the Sparc. ! 218: ! 219: Position-independent code requires special support, and therefore ! 220: works only on certain machines. ! 221: ! 222: `-ffixed-REG' ! 223: Treat the register named REG as a fixed register; generated code ! 224: should never refer to it (except perhaps as a stack pointer, frame ! 225: pointer or in some other fixed role). ! 226: ! 227: REG must be the name of a register. The register names accepted ! 228: are machine-specific and are defined in the `REGISTER_NAMES' macro ! 229: in the machine description macro file. ! 230: ! 231: This flag does not have a negative form, because it specifies a ! 232: three-way choice. ! 233: ! 234: `-fcall-used-REG' ! 235: Treat the register named REG as an allocatable register that is ! 236: clobbered by function calls. It may be allocated for temporaries ! 237: or variables that do not live across a call. Functions compiled ! 238: this way will not save and restore the register REG. ! 239: ! 240: Use of this flag for a register that has a fixed pervasive role in ! 241: the machine's execution model, such as the stack pointer or frame ! 242: pointer, will produce disastrous results. ! 243: ! 244: This flag does not have a negative form, because it specifies a ! 245: three-way choice. ! 246: ! 247: `-fcall-saved-REG' ! 248: Treat the register named REG as an allocatable register saved by ! 249: functions. It may be allocated even for temporaries or variables ! 250: that live across a call. Functions compiled this way will save ! 251: and restore the register REG if they use it. ! 252: ! 253: Use of this flag for a register that has a fixed pervasive role in ! 254: the machine's execution model, such as the stack pointer or frame ! 255: pointer, will produce disastrous results. ! 256: ! 257: A different sort of disaster will result from the use of this flag ! 258: for a register in which function values may be returned. ! 259: ! 260: This flag does not have a negative form, because it specifies a ! 261: three-way choice. ! 262: ! 263: `+e0' ! 264: `+e1' ! 265: Control whether virtual function definitions in classes are used to ! 266: generate code, or only to define interfaces for their callers. ! 267: (C++ only). ! 268: ! 269: These options are provided for compatibility with `cfront' 1.x ! 270: usage; the recommended alternative GNU C++ usage is in flux. ! 271: *Note Declarations and Definitions in One Header: C++ Interface. ! 272: ! 273: With `+e0', virtual function definitions in classes are declared ! 274: `extern'; the declaration is used only as an interface ! 275: specification, not to generate code for the virtual functions (in ! 276: this compilation). ! 277: ! 278: With `+e1', G++ actually generates the code implementing virtual ! 279: functions defined in the code, and makes them publicly visible. ! 280: ! 281: 1.1.1.4 root 282: File: gcc.info, Node: Environment Variables, Next: Running Protoize, Prev: Code Gen Options, Up: Invoking GCC 283: 284: Environment Variables Affecting GNU CC 285: ====================================== 286: 287: This section describes several environment variables that affect how 288: GNU CC operates. They work by specifying directories or prefixes to use 289: when searching for various kinds of files. 290: 291: Note that you can also specify places to search using options such as 292: `-B', `-I' and `-L' (*note Directory Options::.). These take 293: precedence over places specified using environment variables, which in 294: turn take precedence over those specified by the configuration of GNU 295: CC. *Note Driver::. 296: 297: `TMPDIR' 298: If `TMPDIR' is set, it specifies the directory to use for temporary 299: files. GNU CC uses temporary files to hold the output of one 300: stage of compilation which is to be used as input to the next 301: stage: for example, the output of the preprocessor, which is the 302: input to the compiler proper. 303: 304: `GCC_EXEC_PREFIX' 305: If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the 306: names of the subprograms executed by the compiler. No slash is 307: added when this prefix is combined with the name of a subprogram, 308: but you can specify a prefix that ends with a slash if you wish. 309: 310: If GNU CC cannot find the subprogram using the specified prefix, it 311: tries looking in the usual places for the subprogram. 312: 313: Other prefixes specified with `-B' take precedence over this 314: prefix. 315: 316: This prefix is also used for finding files such as `crt0.o' that 317: are used for linking. 318: 319: In addition, the prefix is used in an unusual way in finding the 320: directories to search for header files. For each of the standard 321: directories whose name normally begins with 322: `/usr/local/lib/gcc-lib' (more precisely, with the value of 323: `GCC_INCLUDE_DIR'), GNU CC tries replacing that beginning with the 324: specified prefix to produce an alternate directory name. Thus, 325: with `-Bfoo/', GNU CC will search `foo/bar' where it would 1.1.1.5 ! root 326: normally search `/usr/local/lib/bar'. These alternate directories 1.1.1.4 root 327: are searched first; the standard directories come next. 328: 329: `COMPILER_PATH' 330: The value of `COMPILER_PATH' is a colon-separated list of 331: directories, much like `PATH'. GNU CC tries the directories thus 332: specified when searching for subprograms, if it can't find the 333: subprograms using `GCC_EXEC_PREFIX'. 334: 335: `LIBRARY_PATH' 336: The value of `LIBRARY_PATH' is a colon-separated list of 337: directories, much like `PATH'. GNU CC tries the directories thus 338: specified when searching for special linker files, if it can't 339: find them using `GCC_EXEC_PREFIX'. Linking using GNU CC also uses 340: these directories when searching for ordinary libraries for the 341: `-l' option (but directories specified with `-L' come first). 342: 343: `C_INCLUDE_PATH' 344: `CPLUS_INCLUDE_PATH' 345: `OBJC_INCLUDE_PATH' 346: These environment variables pertain to particular languages. Each 347: variable's value is a colon-separated list of directories, much 348: like `PATH'. When GNU CC searches for header files, it tries the 349: directories listed in the variable for the language you are using, 350: after the directories specified with `-I' but before the standard 351: header file directories. 352: 353: `DEPENDENCIES_OUTPUT' 354: If this variable is set, its value specifies how to output 355: dependencies for Make based on the header files processed by the 356: compiler. This output looks much like the output from the `-M' 357: option (*note Preprocessor Options::.), but it goes to a separate 358: file, and is in addition to the usual results of compilation. 359: 360: The value of `DEPENDENCIES_OUTPUT' can be just a file name, in 361: which case the Make rules are written to that file, guessing the 362: target name from the source file name. Or the value can have the 363: form `FILE TARGET', in which case the rules are written to file 364: FILE using TARGET as the target name. 365: 366: 367: File: gcc.info, Node: Running Protoize, Prev: Environment Variables, Up: Invoking GCC 368: 369: Running Protoize 370: ================ 371: 372: The program `protoize' is an optional part of GNU C. You can use it 373: to add prototypes to a program, thus converting the program to ANSI C 374: in one respect. The companion program `unprotoize' does the reverse: 375: it removes argument types from any prototypes that are found. 376: 377: When you run these programs, you must specify a set of source files 378: as command line arguments. The conversion programs start out by 379: compiling these files to see what functions they define. The 380: information gathered about a file FOO is saved in a file named `FOO.X'. 381: 382: After scanning comes actual conversion. The specified files are all 383: eligible to be converted; any files they include (whether sources or 384: just headers) are eligible as well. 385: 386: But not all the eligible files are converted. By default, 387: `protoize' and `unprotoize' convert only source and header files in the 388: current directory. You can specify additional directories whose files 389: should be converted with the `-d DIRECTORY' option. You can also 390: specify particular files to exclude with the `-x FILE' option. A file 391: is converted if it is eligible, its directory name matches one of the 392: specified directory names, and its name within the directory has not 393: been excluded. 394: 395: Basic conversion with `protoize' consists of rewriting most function 396: definitions and function declarations to specify the types of the 397: arguments. The only ones not rewritten are those for varargs functions. 398: 399: `protoize' optionally inserts prototype declarations at the 400: beginning of the source file, to make them available for any calls that 401: precede the function's definition. Or it can insert prototype 402: declarations with block scope in the blocks where undeclared functions 403: are called. 404: 405: Basic conversion with `unprotoize' consists of rewriting most 406: function declarations to remove any argument types, and rewriting 407: function definitions to the old-style pre-ANSI form. 408: 409: Both conversion programs print a warning for any function 410: declaration or definition that they can't convert. You can suppress 411: these warnings with `-q'. 412: 413: The output from `protoize' or `unprotoize' replaces the original 414: source file. The original file is renamed to a name ending with 415: `.save'. If the `.save' file already exists, then the source file is 416: simply discarded. 417: 418: `protoize' and `unprotoize' both depend on GNU CC itself to scan the 1.1.1.5 ! root 419: program and collect information about the functions it uses. So ! 420: neither of these programs will work until GNU CC is installed. 1.1.1.4 root 421: 422: Here is a table of the options you can use with `protoize' and 423: `unprotoize'. Each option works with both programs unless otherwise 424: stated. 425: 426: `-B DIRECTORY' 427: Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the 428: usual directory (normally `/usr/local/lib'). This file contains 429: prototype information about standard system functions. This option 430: applies only to `protoize'. 431: 432: `-c COMPILATION-OPTIONS' 433: Use COMPILATION-OPTIONS as the options when running `gcc' to 434: produce the `.X' files. The special option `-aux-info' is always 435: passed in addition, to tell `gcc' to write a `.X' file. 436: 437: Note that the compilation options must be given as a single 438: argument to `protoize' or `unprotoize'. If you want to specify 439: several `gcc' options, you must quote the entire set of 440: compilation options to make them a single word in the shell. 441: 442: There are certain `gcc' arguments that you cannot use, because they 443: would produce the wrong kind of output. These include `-g', `-O', 444: `-c', `-S', and `-o' If you include these in the 445: COMPILATION-OPTIONS, they are ignored. 446: 447: `-C' 1.1.1.5 ! root 448: Rename files to end in `.C' instead of `.c'. This is convenient ! 449: if you are converting a C program to C++. This option applies ! 450: only to `protoize'. 1.1.1.4 root 451: 452: `-g' 453: Add explicit global declarations. This means inserting explicit 454: declarations at the beginning of each source file for each function 455: that is called in the file and was not declared. These 456: declarations precede the first function definition that contains a 457: call to an undeclared function. This option applies only to 458: `protoize'. 459: 460: `-i STRING' 461: Indent old-style parameter declarations with the string STRING. 462: This option applies only to `protoize'. 463: 464: `unprotoize' converts prototyped function definitions to old-style 465: function definitions, where the arguments are declared between the 466: argument list and the initial `{'. By default, `unprotoize' uses 467: five spaces as the indentation. If you want to indent with just 468: one space instead, use `-i " "'. 469: 470: `-k' 471: Keep the `.X' files. Normally, they are deleted after conversion 472: is finished. 473: 474: `-l' 475: Add explicit local declarations. `protoize' with `-l' inserts a 476: prototype declaration for each function in each block which calls 477: the function without any declaration. This option applies only to 478: `protoize'. 479: 480: `-n' 481: Make no real changes. This mode just prints information about the 482: conversions that would have been done without `-n'. 483: 484: `-N' 1.1.1.5 ! root 485: Make no `.save' files. The original files are simply deleted. ! 486: Use this option with caution. 1.1.1.4 root 487: 488: `-p PROGRAM' 489: Use the program PROGRAM as the compiler. Normally, the name `gcc' 490: is used. 491: 492: `-q' 493: Work quietly. Most warnings are suppressed. 494: 495: `-v' 496: Print the version number, just like `-v' for `gcc'. 497: 498: If you need special compiler options to compile one of your program's 499: source files, then you should generate that file's `.X' file specially, 500: by running `gcc' on that source file with the appropriate options and 501: the option `-aux-info'. Then run `protoize' on the entire set of 502: files. `protoize' will use the existing `.X' file because it is newer 1.1.1.5 ! root 503: than the source file. For example: 1.1.1.4 root 504: 505: gcc -Dfoo=bar file1.c -aux-info 506: protoize *.c 507: 508: You need to include the special files along with the rest in the 509: `protoize' command, even though their `.X' files already exist, because 510: otherwise they won't get converted. 511: 512: *Note Protoize Caveats::, for more information on how to use 513: `protoize' successfully. 514:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.