![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 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-5 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.9 ! root 1: This is Info file gcc.info, produced by Makeinfo version 1.67 from the ! 2: input file gcc.texi. 1.1 root 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.8 root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330 7: Boston, MA 02111-1307 USA 1.1.1.5 root 8: 1.1.1.8 root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software 10: Foundation, Inc. 1.1 root 11: 1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 1.1 root 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.7 root 18: that the sections entitled "GNU General Public License," "Funding for 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are 20: included exactly as in the original, and provided that the entire 21: resulting derived work is distributed under the terms of a permission 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public 1.1.1.7 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight 28: `Look And Feel'", and this permission notice, may be included in 29: translations approved by the Free Software Foundation instead of in the 30: original English. 31: 32: 1.1.1.8 root 33: File: gcc.info, Node: MIPS Options, Next: i386 Options, Prev: RT Options, Up: Submodel Options 34: 35: MIPS Options 36: ------------ 37: 38: These `-m' options are defined for the MIPS family of computers: 39: 40: `-mcpu=CPU TYPE' 41: Assume the defaults for the machine type CPU TYPE when scheduling 42: instructions. The choices for CPU TYPE are `r2000', `r3000', 43: `r4000', `r4400', `r4600', and `r6000'. While picking a specific 44: CPU TYPE will schedule things appropriately for that particular 45: chip, the compiler will not generate any code that does not meet 46: level 1 of the MIPS ISA (instruction set architecture) without the 47: `-mips2' or `-mips3' switches being used. 48: 49: `-mips1' 50: Issue instructions from level 1 of the MIPS ISA. This is the 51: default. `r3000' is the default CPU TYPE at this ISA level. 52: 53: `-mips2' 54: Issue instructions from level 2 of the MIPS ISA (branch likely, 55: square root instructions). `r6000' is the default CPU TYPE at this 56: ISA level. 57: 58: `-mips3' 59: Issue instructions from level 3 of the MIPS ISA (64 bit 60: instructions). `r4000' is the default CPU TYPE at this ISA level. 61: This option does not change the sizes of any of the C data types. 62: 63: `-mfp32' 64: Assume that 32 32-bit floating point registers are available. 65: This is the default. 66: 67: `-mfp64' 68: Assume that 32 64-bit floating point registers are available. 69: This is the default when the `-mips3' option is used. 70: 71: `-mgp32' 72: Assume that 32 32-bit general purpose registers are available. 73: This is the default. 74: 75: `-mgp64' 76: Assume that 32 64-bit general purpose registers are available. 77: This is the default when the `-mips3' option is used. 78: 79: `-mint64' 80: Types long, int, and pointer are 64 bits. This works only if 81: `-mips3' is also specified. 82: 83: `-mlong64' 84: Types long and pointer are 64 bits, and type int is 32 bits. This 85: works only if `-mips3' is also specified. 86: 87: `-mmips-as' 88: Generate code for the MIPS assembler, and invoke `mips-tfile' to 89: add normal debug information. This is the default for all 90: platforms except for the OSF/1 reference platform, using the 91: OSF/rose object format. If the either of the `-gstabs' or 92: `-gstabs+' switches are used, the `mips-tfile' program will 93: encapsulate the stabs within MIPS ECOFF. 94: 95: `-mgas' 96: Generate code for the GNU assembler. This is the default on the 97: OSF/1 reference platform, using the OSF/rose object format. 98: 99: `-mrnames' 100: `-mno-rnames' 101: The `-mrnames' switch says to output code using the MIPS software 102: names for the registers, instead of the hardware names (ie, A0 103: instead of $4). The only known assembler that supports this option 104: is the Algorithmics assembler. 105: 106: `-mgpopt' 107: `-mno-gpopt' 108: The `-mgpopt' switch says to write all of the data declarations 109: before the instructions in the text section, this allows the MIPS 110: assembler to generate one word memory references instead of using 111: two words for short global or static data items. This is on by 112: default if optimization is selected. 113: 114: `-mstats' 115: `-mno-stats' 116: For each non-inline function processed, the `-mstats' switch 117: causes the compiler to emit one line to the standard error file to 118: print statistics about the program (number of registers saved, 119: stack size, etc.). 120: 121: `-mmemcpy' 122: `-mno-memcpy' 123: The `-mmemcpy' switch makes all block moves call the appropriate 124: string function (`memcpy' or `bcopy') instead of possibly 125: generating inline code. 126: 127: `-mmips-tfile' 128: `-mno-mips-tfile' 129: The `-mno-mips-tfile' switch causes the compiler not postprocess 130: the object file with the `mips-tfile' program, after the MIPS 131: assembler has generated it to add debug support. If `mips-tfile' 132: is not run, then no local variables will be available to the 133: debugger. In addition, `stage2' and `stage3' objects will have 134: the temporary file names passed to the assembler embedded in the 135: object file, which means the objects will not compare the same. 136: The `-mno-mips-tfile' switch should only be used when there are 137: bugs in the `mips-tfile' program that prevents compilation. 138: 139: `-msoft-float' 140: Generate output containing library calls for floating point. 141: *Warning:* the requisite libraries are not part of GNU CC. 142: Normally the facilities of the machine's usual C compiler are 143: used, but this can't be done directly in cross-compilation. You 144: must make your own arrangements to provide suitable library 145: functions for cross-compilation. 146: 147: `-mhard-float' 148: Generate output containing floating point instructions. This is 149: the default if you use the unmodified sources. 150: 151: `-mabicalls' 152: `-mno-abicalls' 153: Emit (or do not emit) the pseudo operations `.abicalls', 154: `.cpload', and `.cprestore' that some System V.4 ports use for 155: position independent code. 156: 157: `-mlong-calls' 158: `-mno-long-calls' 159: Do all calls with the `JALR' instruction, which requires loading 160: up a function's address into a register before the call. You need 161: to use this switch, if you call outside of the current 512 162: megabyte segment to functions that are not through pointers. 163: 164: `-mhalf-pic' 165: `-mno-half-pic' 166: Put pointers to extern references into the data section and load 167: them up, rather than put the references in the text section. 168: 169: `-membedded-pic' 170: `-mno-embedded-pic' 171: Generate PIC code suitable for some embedded systems. All calls 172: are made using PC relative address, and all data is addressed 173: using the $gp register. This requires GNU as and GNU ld which do 174: most of the work. 175: 176: `-membedded-data' 177: `-mno-embedded-data' 178: Allocate variables to the read-only data section first if 179: possible, then next in the small data section if possible, 180: otherwise in data. This gives slightly slower code than the 181: default, but reduces the amount of RAM required when executing, 182: and thus may be preferred for some embedded systems. 183: 184: `-msingle-float' 185: `-mdouble-float' 186: The `-msingle-float' switch tells gcc to assume that the floating 187: point coprocessor only supports single precision operations, as on 188: the `r4650' chip. The `-mdouble-float' switch permits gcc to use 189: double precision operations. This is the default. 190: 191: `-mmad' 192: `-mno-mad' 193: Permit use of the `mad', `madu' and `mul' instructions, as on the 194: `r4650' chip. 195: 196: `-m4650' 197: Turns on `-msingle-float', `-mmad', and, at least for now, 198: `-mcpu=r4650'. 199: 200: `-EL' 201: Compile code for the processor in little endian mode. The 202: requisite libraries are assumed to exist. 203: 204: `-EB' 205: Compile code for the processor in big endian mode. The requisite 206: libraries are assumed to exist. 207: 208: `-G NUM' 209: Put global and static items less than or equal to NUM bytes into 210: the small data or bss sections instead of the normal data or bss 211: section. This allows the assembler to emit one word memory 212: reference instructions based on the global pointer (GP or $28), 213: instead of the normal two words used. By default, NUM is 8 when 214: the MIPS assembler is used, and 0 when the GNU assembler is used. 215: The `-G NUM' switch is also passed to the assembler and linker. 216: All modules should be compiled with the same `-G NUM' value. 217: 218: `-nocpp' 219: Tell the MIPS assembler to not run it's preprocessor over user 220: assembler files (with a `.s' suffix) when assembling them. 221: 222: These options are defined by the macro `TARGET_SWITCHES' in the 223: machine description. The default for the options is also defined by 224: that macro, which enables you to change the defaults. 225: 226: 227: File: gcc.info, Node: i386 Options, Next: HPPA Options, Prev: MIPS Options, Up: Submodel Options 228: 229: Intel 386 Options 230: ----------------- 231: 232: These `-m' options are defined for the i386 family of computers: 233: 234: `-m486' 235: `-m386' 236: Control whether or not code is optimized for a 486 instead of an 237: 386. Code generated for an 486 will run on a 386 and vice versa. 238: 239: `-mieee-fp' 240: `-mno-ieee-fp' 241: Control whether or not the compiler uses IEEE floating point 242: comparisons. These handle correctly the case where the result of a 243: comparison is unordered. 244: 245: `-msoft-float' 246: Generate output containing library calls for floating point. 247: *Warning:* the requisite libraries are not part of GNU CC. 248: Normally the facilities of the machine's usual C compiler are 249: used, but this can't be done directly in cross-compilation. You 250: must make your own arrangements to provide suitable library 251: functions for cross-compilation. 252: 253: On machines where a function returns floating point results in the 254: 80387 register stack, some floating point opcodes may be emitted 255: even if `-msoft-float' is used. 256: 257: `-mno-fp-ret-in-387' 258: Do not use the FPU registers for return values of functions. 259: 260: The usual calling convention has functions return values of types 261: `float' and `double' in an FPU register, even if there is no FPU. 262: The idea is that the operating system should emulate an FPU. 263: 264: The option `-mno-fp-ret-in-387' causes such values to be returned 265: in ordinary CPU registers instead. 266: 267: `-mno-fancy-math-387' 268: Some 387 emulators do not support the `sin', `cos' and `sqrt' 269: instructions for the 387. Specify this option to avoid generating 270: those instructions. This option is the default on FreeBSD. As of 271: revision 2.6.1, these instructions are not generated unless you 272: also use the `-ffast-math' switch. 273: 274: `-malign-double' 275: `-mno-align-double' 276: Control whether GNU CC aligns `double', `long double', and `long 277: long' variables on a two word boundary or a one word boundary. 278: Aligning `double' variables on a two word boundary will produce 279: code that runs somewhat faster on a `Pentium' at the expense of 280: more memory. 281: 282: *Warning:* if you use the `-malign-double' switch, structures 283: containing the above types will be aligned differently than the 284: published application binary interface specifications for the 386. 285: 286: `-msvr3-shlib' 287: `-mno-svr3-shlib' 288: Control whether GNU CC places uninitialized locals into `bss' or 289: `data'. `-msvr3-shlib' places these locals into `bss'. These 290: options are meaningful only on System V Release 3. 291: 292: `-mno-wide-multiply' 293: `-mwide-multiply' 294: Control whether GNU CC uses the `mul' and `imul' that produce 64 295: bit results in `eax:edx' from 32 bit operands to do `long long' 296: multiplies and 32-bit division by constants. 297: 298: `-mrtd' 299: Use a different function-calling convention, in which functions 300: that take a fixed number of arguments return with the `ret' NUM 301: instruction, which pops their arguments while returning. This 302: saves one instruction in the caller since there is no need to pop 303: the arguments there. 304: 305: You can specify that an individual function is called with this 306: calling sequence with the function attribute `stdcall'. You can 307: also override the `-mrtd' option by using the function attribute 308: `cdecl'. *Note Function Attributes:: 309: 310: *Warning:* this calling convention is incompatible with the one 311: normally used on Unix, so you cannot use it if you need to call 312: libraries compiled with the Unix compiler. 313: 314: Also, you must provide function prototypes for all functions that 315: take variable numbers of arguments (including `printf'); otherwise 316: incorrect code will be generated for calls to those functions. 317: 318: In addition, seriously incorrect code will result if you call a 319: function with too many arguments. (Normally, extra arguments are 320: harmlessly ignored.) 321: 322: `-mreg-alloc=REGS' 323: Control the default allocation order of integer registers. The 324: string REGS is a series of letters specifying a register. The 325: supported letters are: `a' allocate EAX; `b' allocate EBX; `c' 326: allocate ECX; `d' allocate EDX; `S' allocate ESI; `D' allocate 327: EDI; `B' allocate EBP. 328: 329: `-mregparm=NUM' 330: Control how many registers are used to pass integer arguments. By 331: default, no registers are used to pass arguments, and at most 3 332: registers can be used. You can control this behavior for a 333: specific function by using the function attribute `regparm'. 334: *Note Function Attributes:: 335: 336: *Warning:* if you use this switch, and NUM is nonzero, then you 337: must build all modules with the same value, including any 338: libraries. This includes the system libraries and startup modules. 339: 340: `-malign-loops=NUM' 341: Align loops to a 2 raised to a NUM byte boundary. If 342: `-malign-loops' is not specified, the default is 2. 343: 344: `-malign-jumps=NUM' 345: Align instructions that are only jumped to to a 2 raised to a NUM 346: byte boundary. If `-malign-jumps' is not specified, the default is 347: 2 if optimizing for a 386, and 4 if optimizing for a 486. 348: 349: `-malign-functions=NUM' 350: Align the start of functions to a 2 raised to NUM byte boundary. 351: If `-malign-jumps' is not specified, the default is 2 if optimizing 352: for a 386, and 4 if optimizing for a 486. 353: 354: 355: File: gcc.info, Node: HPPA Options, Next: Intel 960 Options, Prev: i386 Options, Up: Submodel Options 356: 357: HPPA Options 358: ------------ 359: 360: These `-m' options are defined for the HPPA family of computers: 361: 362: `-mpa-risc-1-0' 363: Generate code for a PA 1.0 processor. 364: 365: `-mpa-risc-1-1' 366: Generate code for a PA 1.1 processor. 367: 368: `-mjump-in-delay' 369: Fill delay slots of function calls with unconditional jump 370: instructions by modifying the return pointer for the function call 371: to be the target of the conditional jump. 372: 373: `-mmillicode-long-calls' 374: Generate code which assumes millicode routines can not be reached 375: by the standard millicode call sequence, linker-generated 376: long-calls, or linker-modified millicode calls. In practice this 377: should only be needed for dynamicly linked executables with 378: extremely large SHLIB_INFO sections. 379: 380: `-mdisable-fpregs' 381: Prevent floating point registers from being used in any manner. 382: This is necessary for compiling kernels which perform lazy context 383: switching of floating point registers. If you use this option and 384: attempt to perform floating point operations, the compiler will 385: abort. 386: 387: `-mdisable-indexing' 388: Prevent the compiler from using indexing address modes. This 389: avoids some rather obscure problems when compiling MIG generated 390: code under MACH. 391: 392: `-mfast-indirect-calls' 393: Generate code which performs faster indirect calls. Such code is 394: suitable for kernels and for static linking. The fast indirect 395: call code will fail miserably if it's part of a dynamically linked 396: executable and in the presense of nested functions. 397: 398: `-mportable-runtime' 399: Use the portable calling conventions proposed by HP for ELF 400: systems. 401: 402: `-mgas' 403: Enable the use of assembler directives only GAS understands. 404: 405: `-mschedule=CPU TYPE' 406: Schedule code according to the constraints for the machine type 407: CPU TYPE. The choices for CPU TYPE are `700' for 7N0 machines, 408: `7100' for 7N5 machines, and `7100' for 7N2 machines. `700' is 409: the default for CPU TYPE. 410: 411: Note the `7100LC' scheduling information is incomplete and using 412: `7100LC' often leads to bad schedules. For now it's probably best 413: to use `7100' instead of `7100LC' for the 7N2 machines. 414: 415: `-msoft-float' 416: Generate output containing library calls for floating point. 417: *Warning:* the requisite libraries are not available for all HPPA 418: targets. Normally the facilities of the machine's usual C 419: compiler are used, but this cannot be done directly in 420: cross-compilation. You must make your own arrangements to provide 421: suitable library functions for cross-compilation. The embedded 422: target `hppa1.1-*-pro' does provide software floating point 423: support. 424: 425: `-msoft-float' changes the calling convention in the output file; 426: therefore, it is only useful if you compile *all* of a program with 427: this option. In particular, you need to compile `libgcc.a', the 428: library that comes with GNU CC, with `-msoft-float' in order for 429: this to work. 430: 431: 432: File: gcc.info, Node: Intel 960 Options, Next: DEC Alpha Options, Prev: HPPA Options, Up: Submodel Options 433: 434: Intel 960 Options 435: ----------------- 436: 437: These `-m' options are defined for the Intel 960 implementations: 438: 439: `-mCPU TYPE' 440: Assume the defaults for the machine type CPU TYPE for some of the 441: other options, including instruction scheduling, floating point 442: support, and addressing modes. The choices for CPU TYPE are `ka', 443: `kb', `mc', `ca', `cf', `sa', and `sb'. The default is `kb'. 444: 445: `-mnumerics' 446: `-msoft-float' 447: The `-mnumerics' option indicates that the processor does support 448: floating-point instructions. The `-msoft-float' option indicates 449: that floating-point support should not be assumed. 450: 451: `-mleaf-procedures' 452: `-mno-leaf-procedures' 453: Do (or do not) attempt to alter leaf procedures to be callable 454: with the `bal' instruction as well as `call'. This will result in 455: more efficient code for explicit calls when the `bal' instruction 456: can be substituted by the assembler or linker, but less efficient 457: code in other cases, such as calls via function pointers, or using 458: a linker that doesn't support this optimization. 459: 460: `-mtail-call' 461: `-mno-tail-call' 462: Do (or do not) make additional attempts (beyond those of the 463: machine-independent portions of the compiler) to optimize 464: tail-recursive calls into branches. You may not want to do this 465: because the detection of cases where this is not valid is not 466: totally complete. The default is `-mno-tail-call'. 467: 468: `-mcomplex-addr' 469: `-mno-complex-addr' 470: Assume (or do not assume) that the use of a complex addressing 471: mode is a win on this implementation of the i960. Complex 472: addressing modes may not be worthwhile on the K-series, but they 473: definitely are on the C-series. The default is currently 474: `-mcomplex-addr' for all processors except the CB and CC. 475: 476: `-mcode-align' 477: `-mno-code-align' 478: Align code to 8-byte boundaries for faster fetching (or don't 479: bother). Currently turned on by default for C-series 480: implementations only. 481: 482: `-mic-compat' 483: `-mic2.0-compat' 484: `-mic3.0-compat' 485: Enable compatibility with iC960 v2.0 or v3.0. 486: 487: `-masm-compat' 488: `-mintel-asm' 489: Enable compatibility with the iC960 assembler. 490: 491: `-mstrict-align' 492: `-mno-strict-align' 493: Do not permit (do permit) unaligned accesses. 494: 495: `-mold-align' 496: Enable structure-alignment compatibility with Intel's gcc release 497: version 1.3 (based on gcc 1.37). Currently this is buggy in that 498: `#pragma align 1' is always assumed as well, and cannot be turned 499: off. 500: 501: 502: File: gcc.info, Node: DEC Alpha Options, Next: Clipper Options, Prev: Intel 960 Options, Up: Submodel Options 503: 504: DEC Alpha Options 505: ----------------- 506: 507: These `-m' options are defined for the DEC Alpha implementations: 508: 509: `-mno-soft-float' 510: `-msoft-float' 511: Use (do not use) the hardware floating-point instructions for 512: floating-point operations. When `-msoft-float' is specified, 513: functions in `libgcc1.c' will be used to perform floating-point 514: operations. Unless they are replaced by routines that emulate the 515: floating-point operations, or compiled in such a way as to call 516: such emulations routines, these routines will issue floating-point 517: operations. If you are compiling for an Alpha without 518: floating-point operations, you must ensure that the library is 519: built so as not to call them. 520: 521: Note that Alpha implementations without floating-point operations 522: are required to have floating-point registers. 523: 524: `-mfp-reg' 525: `-mno-fp-regs' 526: Generate code that uses (does not use) the floating-point register 527: set. `-mno-fp-regs' implies `-msoft-float'. If the floating-point 528: register set is not used, floating point operands are passed in 529: integer registers as if they were integers and floating-point 530: results are passed in $0 instead of $f0. This is a non-standard 531: calling sequence, so any function with a floating-point argument 532: or return value called by code compiled with `-mno-fp-regs' must 533: also be compiled with that option. 534: 535: A typical use of this option is building a kernel that does not 536: use, and hence need not save and restore, any floating-point 537: registers. 538: 539: 540: File: gcc.info, Node: Clipper Options, Next: H8/300 Options, Prev: DEC Alpha Options, Up: Submodel Options 541: 542: Clipper Options 543: --------------- 544: 545: These `-m' options are defined for the Clipper implementations: 546: 547: `-mc300' 548: Produce code for a C300 Clipper processor. This is the default. 549: 550: `-mc400' 551: Produce code for a C400 Clipper processor i.e. use floating point 552: registers f8..f15. 553: 554: 555: File: gcc.info, Node: H8/300 Options, Next: System V Options, Prev: Clipper Options, Up: Submodel Options 556: 557: H8/300 Options 558: -------------- 559: 560: These `-m' options are defined for the H8/300 implementations: 561: 562: `-mrelax' 563: Shorten some address references at link time, when possible; uses 564: the linker option `-relax'. *Note `ld' and the H8/300: 565: (ld.info)H8/300, for a fuller description. 566: 567: `-mh' 568: Generate code for the H8/300H. 569: 570: 571: File: gcc.info, Node: System V Options, Prev: H8/300 Options, Up: Submodel Options 572: 573: Options for System V 574: -------------------- 575: 576: These additional options are available on System V Release 4 for 577: compatibility with other compilers on those systems: 578: 579: `-Qy' 580: Identify the versions of each tool used by the compiler, in a 581: `.ident' assembler directive in the output. 582: 583: `-Qn' 584: Refrain from adding `.ident' directives to the output file (this is 585: the default). 586: 587: `-YP,DIRS' 588: Search the directories DIRS, and no others, for libraries 589: specified with `-l'. 590: 591: `-Ym,DIR' 592: Look in the directory DIR to find the M4 preprocessor. The 593: assembler uses this option. 594: 595: 596: File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC 597: 598: Options for Code Generation Conventions 599: ======================================= 600: 601: These machine-independent options control the interface conventions 602: used in code generation. 603: 604: Most of them have both positive and negative forms; the negative form 605: of `-ffoo' would be `-fno-foo'. In the table below, only one of the 606: forms is listed--the one which is not the default. You can figure out 607: the other form by either removing `no-' or adding it. 608: 609: `-fpcc-struct-return' 610: Return "short" `struct' and `union' values in memory like longer 611: ones, rather than in registers. This convention is less 612: efficient, but it has the advantage of allowing intercallability 613: between GNU CC-compiled files and files compiled with other 614: compilers. 615: 616: The precise convention for returning structures in memory depends 617: on the target configuration macros. 618: 619: Short structures and unions are those whose size and alignment 620: match that of some integer type. 621: 622: `-freg-struct-return' 623: Use the convention that `struct' and `union' values are returned 624: in registers when possible. This is more efficient for small 625: structures than `-fpcc-struct-return'. 626: 627: If you specify neither `-fpcc-struct-return' nor its contrary 628: `-freg-struct-return', GNU CC defaults to whichever convention is 629: standard for the target. If there is no standard convention, GNU 630: CC defaults to `-fpcc-struct-return', except on targets where GNU 631: CC is the principal compiler. In those cases, we can choose the 632: standard, and we chose the more efficient register return 633: alternative. 634: 635: `-fshort-enums' 636: Allocate to an `enum' type only as many bytes as it needs for the 637: declared range of possible values. Specifically, the `enum' type 638: will be equivalent to the smallest integer type which has enough 639: room. 640: 641: `-fshort-double' 642: Use the same size for `double' as for `float'. 643: 644: `-fshared-data' 645: Requests that the data and non-`const' variables of this 646: compilation be shared data rather than private data. The 647: distinction makes sense only on certain operating systems, where 648: shared data is shared between processes running the same program, 649: while private data exists in one copy per process. 650: 651: `-fno-common' 652: Allocate even uninitialized global variables in the bss section of 653: the object file, rather than generating them as common blocks. 654: This has the effect that if the same variable is declared (without 655: `extern') in two different compilations, you will get an error 656: when you link them. The only reason this might be useful is if 657: you wish to verify that the program will work on other systems 658: which always work this way. 659: 660: `-fno-ident' 661: Ignore the `#ident' directive. 662: 663: `-fno-gnu-linker' 664: Do not output global initializations (such as C++ constructors and 665: destructors) in the form used by the GNU linker (on systems where 666: the GNU linker is the standard method of handling them). Use this 667: option when you want to use a non-GNU linker, which also requires 668: using the `collect2' program to make sure the system linker 669: includes constructors and destructors. (`collect2' is included in 670: the GNU CC distribution.) For systems which *must* use 671: `collect2', the compiler driver `gcc' is configured to do this 672: automatically. 673: 674: `-finhibit-size-directive' 675: Don't output a `.size' assembler directive, or anything else that 676: would cause trouble if the function is split in the middle, and the 677: two halves are placed at locations far apart in memory. This 678: option is used when compiling `crtstuff.c'; you should not need to 679: use it for anything else. 680: 681: `-fverbose-asm' 682: Put extra commentary information in the generated assembly code to 683: make it more readable. This option is generally only of use to 684: those who actually need to read the generated assembly code 685: (perhaps while debugging the compiler itself). 686: 687: `-fvolatile' 688: Consider all memory references through pointers to be volatile. 689: 690: `-fvolatile-global' 691: Consider all memory references to extern and global data items to 692: be volatile. 693: 694: `-fpic' 695: Generate position-independent code (PIC) suitable for use in a 696: shared library, if supported for the target machine. Such code 697: accesses all constant addresses through a global offset table 698: (GOT). If the GOT size for the linked executable exceeds a 699: machine-specific maximum size, you get an error message from the 700: linker indicating that `-fpic' does not work; in that case, 701: recompile with `-fPIC' instead. (These maximums are 16k on the 702: m88k, 8k on the Sparc, and 32k on the m68k and RS/6000. The 386 703: has no such limit.) 704: 705: Position-independent code requires special support, and therefore 706: works only on certain machines. For the 386, GNU CC supports PIC 707: for System V but not for the Sun 386i. Code generated for the IBM 708: RS/6000 is always position-independent. 709: 710: The GNU assembler does not fully support PIC. Currently, you must 711: use some other assembler in order for PIC to work. We would 712: welcome volunteers to upgrade GAS to handle this; the first part 713: of the job is to figure out what the assembler must do differently. 714: 715: `-fPIC' 716: If supported for the target machine, emit position-independent 717: code, suitable for dynamic linking and avoiding any limit on the 718: size of the global offset table. This option makes a difference 719: on the m68k, m88k and the Sparc. 720: 721: Position-independent code requires special support, and therefore 722: works only on certain machines. 723: 724: `-ffixed-REG' 725: Treat the register named REG as a fixed register; generated code 726: should never refer to it (except perhaps as a stack pointer, frame 727: pointer or in some other fixed role). 728: 729: REG must be the name of a register. The register names accepted 730: are machine-specific and are defined in the `REGISTER_NAMES' macro 731: in the machine description macro file. 732: 733: This flag does not have a negative form, because it specifies a 734: three-way choice. 735: 736: `-fcall-used-REG' 737: Treat the register named REG as an allocatable register that is 738: clobbered by function calls. It may be allocated for temporaries 739: or variables that do not live across a call. Functions compiled 740: this way will not save and restore the register REG. 741: 742: Use of this flag for a register that has a fixed pervasive role in 743: the machine's execution model, such as the stack pointer or frame 744: pointer, will produce disastrous results. 745: 746: This flag does not have a negative form, because it specifies a 747: three-way choice. 748: 749: `-fcall-saved-REG' 750: Treat the register named REG as an allocatable register saved by 751: functions. It may be allocated even for temporaries or variables 752: that live across a call. Functions compiled this way will save 753: and restore the register REG if they use it. 754: 755: Use of this flag for a register that has a fixed pervasive role in 756: the machine's execution model, such as the stack pointer or frame 757: pointer, will produce disastrous results. 758: 759: A different sort of disaster will result from the use of this flag 760: for a register in which function values may be returned. 761: 762: This flag does not have a negative form, because it specifies a 763: three-way choice. 764: 765: `-fpack-struct' 766: Pack all structure members together without holes. Usually you 767: would not want to use this option, since it makes the code 768: suboptimal, and the offsets of structure members won't agree with 769: system libraries. 770: 771: `+e0' 772: `+e1' 773: Control whether virtual function definitions in classes are used to 774: generate code, or only to define interfaces for their callers. 775: (C++ only). 776: 777: These options are provided for compatibility with `cfront' 1.x 778: usage; the recommended alternative GNU C++ usage is in flux. 779: *Note Declarations and Definitions in One Header: C++ Interface. 780: 781: With `+e0', virtual function definitions in classes are declared 782: `extern'; the declaration is used only as an interface 783: specification, not to generate code for the virtual functions (in 784: this compilation). 785: 786: With `+e1', G++ actually generates the code implementing virtual 787: functions defined in the code, and makes them publicly visible. 788: 789: 1.1.1.7 root 790: File: gcc.info, Node: Environment Variables, Next: Running Protoize, Prev: Code Gen Options, Up: Invoking GCC 791: 792: Environment Variables Affecting GNU CC 793: ====================================== 794: 795: This section describes several environment variables that affect how 796: GNU CC operates. They work by specifying directories or prefixes to use 797: when searching for various kinds of files. 798: 799: Note that you can also specify places to search using options such as 800: `-B', `-I' and `-L' (*note Directory Options::.). These take 801: precedence over places specified using environment variables, which in 802: turn take precedence over those specified by the configuration of GNU 803: CC. *Note Driver::. 804: 805: `TMPDIR' 806: If `TMPDIR' is set, it specifies the directory to use for temporary 807: files. GNU CC uses temporary files to hold the output of one 808: stage of compilation which is to be used as input to the next 809: stage: for example, the output of the preprocessor, which is the 810: input to the compiler proper. 811: 812: `GCC_EXEC_PREFIX' 813: If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the 814: names of the subprograms executed by the compiler. No slash is 815: added when this prefix is combined with the name of a subprogram, 816: but you can specify a prefix that ends with a slash if you wish. 817: 818: If GNU CC cannot find the subprogram using the specified prefix, it 819: tries looking in the usual places for the subprogram. 820: 1.1.1.8 root 821: The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc-lib/' 822: where PREFIX is the value of `prefix' when you ran the `configure' 823: script. 1.1.1.7 root 824: 825: Other prefixes specified with `-B' take precedence over this 826: prefix. 827: 828: This prefix is also used for finding files such as `crt0.o' that 829: are used for linking. 830: 831: In addition, the prefix is used in an unusual way in finding the 832: directories to search for header files. For each of the standard 833: directories whose name normally begins with 834: `/usr/local/lib/gcc-lib' (more precisely, with the value of 835: `GCC_INCLUDE_DIR'), GNU CC tries replacing that beginning with the 836: specified prefix to produce an alternate directory name. Thus, 837: with `-Bfoo/', GNU CC will search `foo/bar' where it would 838: normally search `/usr/local/lib/bar'. These alternate directories 839: are searched first; the standard directories come next. 840: 841: `COMPILER_PATH' 842: The value of `COMPILER_PATH' is a colon-separated list of 843: directories, much like `PATH'. GNU CC tries the directories thus 844: specified when searching for subprograms, if it can't find the 845: subprograms using `GCC_EXEC_PREFIX'. 846: 847: `LIBRARY_PATH' 848: The value of `LIBRARY_PATH' is a colon-separated list of 1.1.1.8 root 849: directories, much like `PATH'. When configured as a native 850: compiler, GNU CC tries the directories thus specified when 851: searching for special linker files, if it can't find them using 852: `GCC_EXEC_PREFIX'. Linking using GNU CC also uses these 853: directories when searching for ordinary libraries for the `-l' 854: option (but directories specified with `-L' come first). 1.1.1.7 root 855: 856: `C_INCLUDE_PATH' 857: `CPLUS_INCLUDE_PATH' 858: `OBJC_INCLUDE_PATH' 859: These environment variables pertain to particular languages. Each 860: variable's value is a colon-separated list of directories, much 861: like `PATH'. When GNU CC searches for header files, it tries the 862: directories listed in the variable for the language you are using, 863: after the directories specified with `-I' but before the standard 864: header file directories. 865: 866: `DEPENDENCIES_OUTPUT' 867: If this variable is set, its value specifies how to output 868: dependencies for Make based on the header files processed by the 869: compiler. This output looks much like the output from the `-M' 870: option (*note Preprocessor Options::.), but it goes to a separate 871: file, and is in addition to the usual results of compilation. 872: 873: The value of `DEPENDENCIES_OUTPUT' can be just a file name, in 874: which case the Make rules are written to that file, guessing the 875: target name from the source file name. Or the value can have the 876: form `FILE TARGET', in which case the rules are written to file 877: FILE using TARGET as the target name. 878: 879: 880: File: gcc.info, Node: Running Protoize, Prev: Environment Variables, Up: Invoking GCC 881: 882: Running Protoize 883: ================ 884: 885: The program `protoize' is an optional part of GNU C. You can use it 886: to add prototypes to a program, thus converting the program to ANSI C 887: in one respect. The companion program `unprotoize' does the reverse: 888: it removes argument types from any prototypes that are found. 889: 890: When you run these programs, you must specify a set of source files 891: as command line arguments. The conversion programs start out by 892: compiling these files to see what functions they define. The 893: information gathered about a file FOO is saved in a file named `FOO.X'. 894: 895: After scanning comes actual conversion. The specified files are all 896: eligible to be converted; any files they include (whether sources or 897: just headers) are eligible as well. 898: 899: But not all the eligible files are converted. By default, 900: `protoize' and `unprotoize' convert only source and header files in the 901: current directory. You can specify additional directories whose files 902: should be converted with the `-d DIRECTORY' option. You can also 903: specify particular files to exclude with the `-x FILE' option. A file 904: is converted if it is eligible, its directory name matches one of the 905: specified directory names, and its name within the directory has not 906: been excluded. 907: 908: Basic conversion with `protoize' consists of rewriting most function 909: definitions and function declarations to specify the types of the 910: arguments. The only ones not rewritten are those for varargs functions. 911: 912: `protoize' optionally inserts prototype declarations at the 913: beginning of the source file, to make them available for any calls that 914: precede the function's definition. Or it can insert prototype 915: declarations with block scope in the blocks where undeclared functions 916: are called. 917: 918: Basic conversion with `unprotoize' consists of rewriting most 919: function declarations to remove any argument types, and rewriting 920: function definitions to the old-style pre-ANSI form. 921: 922: Both conversion programs print a warning for any function 923: declaration or definition that they can't convert. You can suppress 924: these warnings with `-q'. 925: 926: The output from `protoize' or `unprotoize' replaces the original 927: source file. The original file is renamed to a name ending with 928: `.save'. If the `.save' file already exists, then the source file is 929: simply discarded. 930: 931: `protoize' and `unprotoize' both depend on GNU CC itself to scan the 932: program and collect information about the functions it uses. So 933: neither of these programs will work until GNU CC is installed. 934: 935: Here is a table of the options you can use with `protoize' and 936: `unprotoize'. Each option works with both programs unless otherwise 937: stated. 938: 939: `-B DIRECTORY' 940: Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the 941: usual directory (normally `/usr/local/lib'). This file contains 942: prototype information about standard system functions. This option 943: applies only to `protoize'. 944: 945: `-c COMPILATION-OPTIONS' 946: Use COMPILATION-OPTIONS as the options when running `gcc' to 947: produce the `.X' files. The special option `-aux-info' is always 948: passed in addition, to tell `gcc' to write a `.X' file. 949: 950: Note that the compilation options must be given as a single 951: argument to `protoize' or `unprotoize'. If you want to specify 952: several `gcc' options, you must quote the entire set of 953: compilation options to make them a single word in the shell. 954: 955: There are certain `gcc' arguments that you cannot use, because they 956: would produce the wrong kind of output. These include `-g', `-O', 957: `-c', `-S', and `-o' If you include these in the 958: COMPILATION-OPTIONS, they are ignored. 959: 960: `-C' 961: Rename files to end in `.C' instead of `.c'. This is convenient 962: if you are converting a C program to C++. This option applies 963: only to `protoize'. 964: 965: `-g' 966: Add explicit global declarations. This means inserting explicit 967: declarations at the beginning of each source file for each function 968: that is called in the file and was not declared. These 969: declarations precede the first function definition that contains a 970: call to an undeclared function. This option applies only to 971: `protoize'. 972: 973: `-i STRING' 974: Indent old-style parameter declarations with the string STRING. 975: This option applies only to `protoize'. 976: 977: `unprotoize' converts prototyped function definitions to old-style 978: function definitions, where the arguments are declared between the 979: argument list and the initial `{'. By default, `unprotoize' uses 980: five spaces as the indentation. If you want to indent with just 981: one space instead, use `-i " "'. 982: 983: `-k' 984: Keep the `.X' files. Normally, they are deleted after conversion 985: is finished. 986: 987: `-l' 988: Add explicit local declarations. `protoize' with `-l' inserts a 989: prototype declaration for each function in each block which calls 990: the function without any declaration. This option applies only to 991: `protoize'. 992: 993: `-n' 994: Make no real changes. This mode just prints information about the 995: conversions that would have been done without `-n'. 996: 997: `-N' 998: Make no `.save' files. The original files are simply deleted. 999: Use this option with caution. 1000: 1001: `-p PROGRAM' 1002: Use the program PROGRAM as the compiler. Normally, the name `gcc' 1003: is used. 1004: 1005: `-q' 1006: Work quietly. Most warnings are suppressed. 1007: 1008: `-v' 1009: Print the version number, just like `-v' for `gcc'. 1010: 1011: If you need special compiler options to compile one of your program's 1012: source files, then you should generate that file's `.X' file specially, 1013: by running `gcc' on that source file with the appropriate options and 1014: the option `-aux-info'. Then run `protoize' on the entire set of 1015: files. `protoize' will use the existing `.X' file because it is newer 1016: than the source file. For example: 1017: 1018: gcc -Dfoo=bar file1.c -aux-info 1019: protoize *.c 1020: 1021: You need to include the special files along with the rest in the 1022: `protoize' command, even though their `.X' files already exist, because 1023: otherwise they won't get converted. 1024: 1025: *Note Protoize Caveats::, for more information on how to use 1026: `protoize' successfully. 1.1 root 1027:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.