![[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.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: Directory Options, Next: Target Options, Prev: Link Options, Up: Invoking GCC 34: 35: Options for Directory Search 36: ============================ 37: 38: These options specify directories to search for header files, for 39: libraries and for parts of the compiler: 40: 41: `-IDIR' 42: Add the directory DIRECTORY to the head of the list of directories 43: to be searched for header files. This can be used to override a 44: system header file, substituting your own version, since these 45: directories are searched before the system header file 46: directories. If you use more than one `-I' option, the 47: directories are scanned in left-to-right order; the standard 48: system directories come after. 49: 50: `-I-' 51: Any directories you specify with `-I' options before the `-I-' 52: option are searched only for the case of `#include "FILE"'; they 53: are not searched for `#include <FILE>'. 54: 55: If additional directories are specified with `-I' options after 56: the `-I-', these directories are searched for all `#include' 57: directives. (Ordinarily *all* `-I' directories are used this way.) 58: 59: In addition, the `-I-' option inhibits the use of the current 60: directory (where the current input file came from) as the first 61: search directory for `#include "FILE"'. There is no way to 62: override this effect of `-I-'. With `-I.' you can specify 63: searching the directory which was current when the compiler was 64: invoked. That is not exactly the same as what the preprocessor 65: does by default, but it is often satisfactory. 66: 67: `-I-' does not inhibit the use of the standard system directories 68: for header files. Thus, `-I-' and `-nostdinc' are independent. 69: 70: `-LDIR' 71: Add directory DIR to the list of directories to be searched for 72: `-l'. 73: 74: `-BPREFIX' 75: This option specifies where to find the executables, libraries, 76: include files, and data files of the compiler itself. 77: 78: The compiler driver program runs one or more of the subprograms 79: `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for each 80: program it tries to run, both with and without `MACHINE/VERSION/' 81: (*note Target Options::.). 82: 83: For each subprogram to be run, the compiler driver first tries the 84: `-B' prefix, if any. If that name is not found, or if `-B' was 85: not specified, the driver tries two standard prefixes, which are 86: `/usr/lib/gcc/' and `/usr/local/lib/gcc-lib/'. If neither of 87: those results in a file name that is found, the unmodified program 88: name is searched for using the directories specified in your 89: `PATH' environment variable. 90: 91: `-B' prefixes that effectively specify directory names also apply 92: to libraries in the linker, because the compiler translates these 93: options into `-L' options for the linker. They also apply to 94: includes files in the preprocessor, because the compiler 95: translates these options into `-isystem' options for the 96: preprocessor. In this case, the compiler appends `include' to the 97: prefix. 98: 99: The run-time support file `libgcc.a' can also be searched for using 100: the `-B' prefix, if needed. If it is not found there, the two 101: standard prefixes above are tried, and that is all. The file is 102: left out of the link if it is not found by those means. 103: 104: Another way to specify a prefix much like the `-B' prefix is to use 105: the environment variable `GCC_EXEC_PREFIX'. *Note Environment 106: Variables::. 107: 108: 109: File: gcc.info, Node: Target Options, Next: Submodel Options, Prev: Directory Options, Up: Invoking GCC 110: 111: Specifying Target Machine and Compiler Version 112: ============================================== 113: 114: By default, GNU CC compiles code for the same type of machine that 115: you are using. However, it can also be installed as a cross-compiler, 116: to compile for some other type of machine. In fact, several different 117: configurations of GNU CC, for different target machines, can be 118: installed side by side. Then you specify which one to use with the 119: `-b' option. 120: 121: In addition, older and newer versions of GNU CC can be installed side 122: by side. One of them (probably the newest) will be the default, but 123: you may sometimes wish to use another. 124: 125: `-b MACHINE' 126: The argument MACHINE specifies the target machine for compilation. 127: This is useful when you have installed GNU CC as a cross-compiler. 128: 129: The value to use for MACHINE is the same as was specified as the 130: machine type when configuring GNU CC as a cross-compiler. For 131: example, if a cross-compiler was configured with `configure 132: i386v', meaning to compile for an 80386 running System V, then you 133: would specify `-b i386v' to run that cross compiler. 134: 135: When you do not specify `-b', it normally means to compile for the 136: same type of machine that you are using. 137: 138: `-V VERSION' 139: The argument VERSION specifies which version of GNU CC to run. 140: This is useful when multiple versions are installed. For example, 141: VERSION might be `2.0', meaning to run GNU CC version 2.0. 142: 143: The default version, when you do not specify `-V', is the last 144: version of GNU CC that you installed. 145: 146: The `-b' and `-V' options actually work by controlling part of the 147: file name used for the executable files and libraries used for 148: compilation. A given version of GNU CC, for a given target machine, is 149: normally kept in the directory `/usr/local/lib/gcc-lib/MACHINE/VERSION'. 150: 151: Thus, sites can customize the effect of `-b' or `-V' either by 152: changing the names of these directories or adding alternate names (or 153: symbolic links). If in directory `/usr/local/lib/gcc-lib/' the file 154: `80386' is a link to the file `i386v', then `-b 80386' becomes an alias 155: for `-b i386v'. 156: 157: In one respect, the `-b' or `-V' do not completely change to a 158: different compiler: the top-level driver program `gcc' that you 159: originally invoked continues to run and invoke the other executables 160: (preprocessor, compiler per se, assembler and linker) that do the real 161: work. However, since no real work is done in the driver program, it 162: usually does not matter that the driver program in use is not the one 163: for the specified target and version. 164: 165: The only way that the driver program depends on the target machine is 166: in the parsing and handling of special machine-specific options. 167: However, this is controlled by a file which is found, along with the 168: other executables, in the directory for the specified version and 169: target machine. As a result, a single installed driver program adapts 170: to any specified target machine and compiler version. 171: 172: The driver program executable does control one significant thing, 173: however: the default version and target machine. Therefore, you can 174: install different instances of the driver program, compiled for 175: different targets or versions, under different names. 176: 177: For example, if the driver for version 2.0 is installed as `ogcc' 178: and that for version 2.1 is installed as `gcc', then the command `gcc' 179: will use version 2.1 by default, while `ogcc' will use 2.0 by default. 180: However, you can choose either version with either command with the 181: `-V' option. 182: 183: 184: File: gcc.info, Node: Submodel Options, Next: Code Gen Options, Prev: Target Options, Up: Invoking GCC 185: 186: Hardware Models and Configurations 187: ================================== 188: 189: Earlier we discussed the standard option `-b' which chooses among 190: different installed compilers for completely different target machines, 191: such as Vax vs. 68000 vs. 80386. 192: 193: In addition, each of these target machine types can have its own 194: special options, starting with `-m', to choose among various hardware 195: models or configurations--for example, 68010 vs 68020, floating 196: coprocessor or none. A single installed version of the compiler can 197: compile for any model or configuration, according to the options 198: specified. 199: 200: Some configurations of the compiler also support additional special 201: options, usually for compatibility with other compilers on the same 202: platform. 203: 204: These options are defined by the macro `TARGET_SWITCHES' in the 205: machine description. The default for the options is also defined by 206: that macro, which enables you to change the defaults. 207: 208: * Menu: 209: 210: * M680x0 Options:: 211: * VAX Options:: 212: * SPARC Options:: 213: * Convex Options:: 214: * AMD29K Options:: 215: * ARM Options:: 216: * M88K Options:: 217: * RS/6000 and PowerPC Options:: 218: * RT Options:: 219: * MIPS Options:: 220: * i386 Options:: 221: * HPPA Options:: 222: * Intel 960 Options:: 223: * DEC Alpha Options:: 224: * Clipper Options:: 225: * H8/300 Options:: 226: * System V Options:: 227: 228: 229: File: gcc.info, Node: M680x0 Options, Next: VAX Options, Up: Submodel Options 230: 231: M680x0 Options 232: -------------- 233: 234: These are the `-m' options defined for the 68000 series. The default 235: values for these options depends on which style of 68000 was selected 236: when the compiler was configured; the defaults for the most common 237: choices are given below. 238: 239: `-m68000' 240: `-mc68000' 241: Generate output for a 68000. This is the default when the 242: compiler is configured for 68000-based systems. 243: 244: `-m68020' 245: `-mc68020' 246: Generate output for a 68020. This is the default when the 247: compiler is configured for 68020-based systems. 248: 249: `-m68881' 250: Generate output containing 68881 instructions for floating point. 251: This is the default for most 68020 systems unless `-nfp' was 252: specified when the compiler was configured. 253: 254: `-m68030' 255: Generate output for a 68030. This is the default when the 256: compiler is configured for 68030-based systems. 257: 258: `-m68040' 259: Generate output for a 68040. This is the default when the 260: compiler is configured for 68040-based systems. 261: 262: This option inhibits the use of 68881/68882 instructions that have 263: to be emulated by software on the 68040. If your 68040 does not 264: have code to emulate those instructions, use `-m68040'. 265: 266: `-m68020-40' 267: Generate output for a 68040, without using any of the new 268: instructions. This results in code which can run relatively 269: efficiently on either a 68020/68881 or a 68030 or a 68040. The 270: generated code does use the 68881 instructions that are emulated 271: on the 68040. 272: 273: `-mfpa' 274: Generate output containing Sun FPA instructions for floating point. 275: 276: `-msoft-float' 277: Generate output containing library calls for floating point. 278: *Warning:* the requisite libraries are not available for all m68k 279: targets. Normally the facilities of the machine's usual C 280: compiler are used, but this can't be done directly in 281: cross-compilation. You must make your own arrangements to provide 282: suitable library functions for cross-compilation. The embedded 283: targets `m68k-*-aout' and `m68k-*-coff' do provide software 284: floating point support. 285: 286: `-mshort' 287: Consider type `int' to be 16 bits wide, like `short int'. 288: 289: `-mnobitfield' 290: Do not use the bit-field instructions. The `-m68000' option 291: implies `-mnobitfield'. 292: 293: `-mbitfield' 294: Do use the bit-field instructions. The `-m68020' option implies 295: `-mbitfield'. This is the default if you use a configuration 296: designed for a 68020. 297: 298: `-mrtd' 299: Use a different function-calling convention, in which functions 300: that take a fixed number of arguments return with the `rtd' 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: This calling convention is incompatible with the one normally used 306: on Unix, so you cannot use it if you need to call libraries 307: compiled with the Unix compiler. 308: 309: Also, you must provide function prototypes for all functions that 310: take variable numbers of arguments (including `printf'); otherwise 311: incorrect code will be generated for calls to those functions. 312: 313: In addition, seriously incorrect code will result if you call a 314: function with too many arguments. (Normally, extra arguments are 315: harmlessly ignored.) 316: 317: The `rtd' instruction is supported by the 68010 and 68020 318: processors, but not by the 68000. 319: 320: 321: File: gcc.info, Node: VAX Options, Next: SPARC Options, Prev: M680x0 Options, Up: Submodel Options 322: 323: VAX Options 324: ----------- 325: 326: These `-m' options are defined for the Vax: 327: 328: `-munix' 329: Do not output certain jump instructions (`aobleq' and so on) that 330: the Unix assembler for the Vax cannot handle across long ranges. 331: 332: `-mgnu' 333: Do output those jump instructions, on the assumption that you will 334: assemble with the GNU assembler. 335: 336: `-mg' 337: Output code for g-format floating point numbers instead of 338: d-format. 339: 340: 341: File: gcc.info, Node: SPARC Options, Next: Convex Options, Prev: VAX Options, Up: Submodel Options 342: 343: SPARC Options 344: ------------- 345: 346: These `-m' switches are supported on the SPARC: 347: 348: `-mno-app-regs' 349: `-mapp-regs' 350: Specify `-mapp-regs' to generate output using the global registers 351: 2 through 4, which the SPARC SVR4 ABI reserves for applications. 352: This is the default. 353: 354: To be fully SVR4 ABI compliant at the cost of some performance 355: loss, specify `-mno-app-regs'. You should compile libraries and 356: system software with this option. 357: 358: `-mfpu' 359: `-mhard-float' 360: Generate output containing floating point instructions. This is 361: the default. 362: 363: `-mno-fpu' 364: `-msoft-float' 365: Generate output containing library calls for floating point. 366: *Warning:* the requisite libraries are not available for all SPARC 367: targets. Normally the facilities of the machine's usual C 368: compiler are used, but this cannot be done directly in 369: cross-compilation. You must make your own arrangements to provide 370: suitable library functions for cross-compilation. The embedded 371: targets `sparc-*-aout' and `sparclite-*-*' do provide software 372: floating point support. 373: 374: `-msoft-float' changes the calling convention in the output file; 375: therefore, it is only useful if you compile *all* of a program with 376: this option. In particular, you need to compile `libgcc.a', the 377: library that comes with GNU CC, with `-msoft-float' in order for 378: this to work. 379: 380: `-mhard-quad-float' 381: Generate output containing quad-word (long double) floating point 382: instructions. 383: 384: `-msoft-quad-float' 385: Generate output containing library calls for quad-word (long 386: double) floating point instructions. The functions called are 387: those specified in the SPARC ABI. This is the default. 388: 389: As of this writing, there are no sparc implementations that have 390: hardware support for the quad-word floating point instructions. 391: They all invoke a trap handler for one of these instructions, and 392: then the trap handler emulates the effect of the instruction. 393: Because of the trap handler overhead, this is much slower than 394: calling the ABI library routines. Thus the `-msoft-quad-float' 395: option is the default. 396: 397: `-mno-epilogue' 398: `-mepilogue' 399: With `-mepilogue' (the default), the compiler always emits code for 400: function exit at the end of each function. Any function exit in 401: the middle of the function (such as a return statement in C) will 402: generate a jump to the exit code at the end of the function. 403: 404: With `-mno-epilogue', the compiler tries to emit exit code inline 405: at every function exit. 406: 407: `-mno-flat' 408: `-mflat' 409: With `-mflat', the compiler does not generate save/restore 410: instructions and will use a "flat" or single register window 411: calling convention. This model uses %i7 as the frame pointer and 412: is compatible with the normal register window model. Code from 413: either may be intermixed although debugger support is still 414: incomplete. The local registers and the input registers (0-5) are 415: still treated as "call saved" registers and will be saved on the 416: stack as necessary. 417: 418: With `-mno-flat' (the default), the compiler emits save/restore 419: instructions (except for leaf functions) and is the normal mode of 420: operation. 421: 422: `-mno-unaligned-doubles' 423: `-munaligned-doubles' 424: Assume that doubles have 8 byte alignment. This is the default. 425: 426: With `-munaligned-doubles', GNU CC assumes that doubles have 8 byte 427: alignment only if they are contained in another type, or if they 428: have an absolute address. Otherwise, it assumes they have 4 byte 429: alignment. Specifying this option avoids some rare compatibility 430: problems with code generated by other compilers. It is not the 431: default because it results in a performance loss, especially for 432: floating point code. 433: 434: `-mv8' 435: `-msparclite' 436: These two options select variations on the SPARC architecture. 437: 438: By default (unless specifically configured for the Fujitsu 439: SPARClite), GCC generates code for the v7 variant of the SPARC 440: architecture. 441: 442: `-mv8' will give you SPARC v8 code. The only difference from v7 443: code is that the compiler emits the integer multiply and integer 444: divide instructions which exist in SPARC v8 but not in SPARC v7. 445: 446: `-msparclite' will give you SPARClite code. This adds the integer 447: multiply, integer divide step and scan (`ffs') instructions which 448: exist in SPARClite but not in SPARC v7. 449: 450: `-mcypress' 451: `-msupersparc' 452: These two options select the processor for which the code is 453: optimised. 454: 455: With `-mcypress' (the default), the compiler optimizes code for the 456: Cypress CY7C602 chip, as used in the SparcStation/SparcServer 3xx 457: series. This is also appropriate for the older SparcStation 1, 2, 458: IPX etc. 459: 460: With `-msupersparc' the compiler optimizes code for the SuperSparc 461: cpu, as used in the SparcStation 10, 1000 and 2000 series. This 462: flag also enables use of the full SPARC v8 instruction set. 463: 464: In a future version of GCC, these options will very likely be 465: renamed to `-mcpu=cypress' and `-mcpu=supersparc'. 466: 467: These `-m' switches are supported in addition to the above on SPARC 468: V9 processors: 469: 470: `-mmedlow' 471: Generate code for the Medium/Low code model: assume a 32 bit 472: address space. Programs are statically linked, PIC is not 473: supported. Pointers are still 64 bits. 474: 475: It is very likely that a future version of GCC will rename this 476: option. 477: 478: `-mmedany' 479: Generate code for the Medium/Anywhere code model: assume a 32 bit 480: text segment starting at offset 0, and a 32 bit data segment 481: starting anywhere (determined at link time). Programs are 482: statically linked, PIC is not supported. Pointers are still 64 483: bits. 484: 485: It is very likely that a future version of GCC will rename this 486: option. 487: 488: `-mint64' 489: Types long and int are 64 bits. 490: 491: `-mlong32' 492: Types long and int are 32 bits. 493: 494: `-mlong64' 495: `-mint32' 496: Type long is 64 bits, and type int is 32 bits. 497: 498: `-mstack-bias' 499: `-mno-stack-bias' 500: With `-mstack-bias', GNU CC assumes that the stack pointer, and 501: frame pointer if present, are offset by -2047 which must be added 502: back when making stack frame references. Otherwise, assume no 503: such offset is present. 504: 505: 1.1.1.7 root 506: File: gcc.info, Node: Convex Options, Next: AMD29K Options, Prev: SPARC Options, Up: Submodel Options 507: 508: Convex Options 509: -------------- 510: 511: These `-m' options are defined for Convex: 512: 513: `-mc1' 514: Generate output for C1. The code will run on any Convex machine. 515: The preprocessor symbol `__convex__c1__' is defined. 516: 517: `-mc2' 518: Generate output for C2. Uses instructions not available on C1. 519: Scheduling and other optimizations are chosen for max performance 520: on C2. The preprocessor symbol `__convex_c2__' is defined. 521: 522: `-mc32' 523: Generate output for C32xx. Uses instructions not available on C1. 524: Scheduling and other optimizations are chosen for max performance 525: on C32. The preprocessor symbol `__convex_c32__' is defined. 526: 527: `-mc34' 528: Generate output for C34xx. Uses instructions not available on C1. 529: Scheduling and other optimizations are chosen for max performance 530: on C34. The preprocessor symbol `__convex_c34__' is defined. 531: 532: `-mc38' 533: Generate output for C38xx. Uses instructions not available on C1. 534: Scheduling and other optimizations are chosen for max performance 535: on C38. The preprocessor symbol `__convex_c38__' is defined. 536: 537: `-margcount' 538: Generate code which puts an argument count in the word preceding 539: each argument list. This is compatible with regular CC, and a few 540: programs may need the argument count word. GDB and other 541: source-level debuggers do not need it; this info is in the symbol 542: table. 543: 544: `-mnoargcount' 545: Omit the argument count word. This is the default. 546: 547: `-mvolatile-cache' 548: Allow volatile references to be cached. This is the default. 549: 550: `-mvolatile-nocache' 551: Volatile references bypass the data cache, going all the way to 552: memory. This is only needed for multi-processor code that does 553: not use standard synchronization instructions. Making 554: non-volatile references to volatile locations will not necessarily 555: work. 556: 557: `-mlong32' 558: Type long is 32 bits, the same as type int. This is the default. 559: 560: `-mlong64' 561: Type long is 64 bits, the same as type long long. This option is 562: useless, because no library support exists for it. 563: 564: 565: File: gcc.info, Node: AMD29K Options, Next: ARM Options, Prev: Convex Options, Up: Submodel Options 566: 567: AMD29K Options 568: -------------- 569: 570: These `-m' options are defined for the AMD Am29000: 571: 572: `-mdw' 573: Generate code that assumes the `DW' bit is set, i.e., that byte and 574: halfword operations are directly supported by the hardware. This 575: is the default. 576: 577: `-mndw' 578: Generate code that assumes the `DW' bit is not set. 579: 580: `-mbw' 581: Generate code that assumes the system supports byte and halfword 582: write operations. This is the default. 583: 584: `-mnbw' 585: Generate code that assumes the systems does not support byte and 586: halfword write operations. `-mnbw' implies `-mndw'. 587: 588: `-msmall' 589: Use a small memory model that assumes that all function addresses 590: are either within a single 256 KB segment or at an absolute 591: address of less than 256k. This allows the `call' instruction to 592: be used instead of a `const', `consth', `calli' sequence. 593: 594: `-mnormal' 595: Use the normal memory model: Generate `call' instructions only when 596: calling functions in the same file and `calli' instructions 597: otherwise. This works if each file occupies less than 256 KB but 598: allows the entire executable to be larger than 256 KB. This is 599: the default. 600: 601: `-mlarge' 602: Always use `calli' instructions. Specify this option if you expect 603: a single file to compile into more than 256 KB of code. 604: 605: `-m29050' 606: Generate code for the Am29050. 607: 608: `-m29000' 609: Generate code for the Am29000. This is the default. 610: 611: `-mkernel-registers' 612: Generate references to registers `gr64-gr95' instead of to 613: registers `gr96-gr127'. This option can be used when compiling 614: kernel code that wants a set of global registers disjoint from 615: that used by user-mode code. 616: 617: Note that when this option is used, register names in `-f' flags 618: must use the normal, user-mode, names. 619: 620: `-muser-registers' 621: Use the normal set of global registers, `gr96-gr127'. This is the 622: default. 623: 624: `-mstack-check' 625: `-mno-stack-check' 626: Insert (or do not insert) a call to `__msp_check' after each stack 627: adjustment. This is often used for kernel code. 628: 629: `-mstorem-bug' 630: `-mno-storem-bug' 631: `-mstorem-bug' handles 29k processors which cannot handle the 632: separation of a mtsrim insn and a storem instruction (most 29000 633: chips to date, but not the 29050). 634: 635: `-mno-reuse-arg-regs' 636: `-mreuse-arg-regs' 637: `-mno-reuse-arg-regs' tells the compiler to only use incoming 638: argument registers for copying out arguments. This helps detect 639: calling a function with fewer arguments than it was declared with. 640: 641: `-msoft-float' 642: Generate output containing library calls for floating point. 643: *Warning:* the requisite libraries are not part of GNU CC. 644: Normally the facilities of the machine's usual C compiler are 645: used, but this can't be done directly in cross-compilation. You 646: must make your own arrangements to provide suitable library 647: functions for cross-compilation. 648: 649: 650: File: gcc.info, Node: ARM Options, Next: M88K Options, Prev: AMD29K Options, Up: Submodel Options 651: 652: ARM Options 653: ----------- 654: 655: These `-m' options are defined for Advanced RISC Machines (ARM) 656: architectures: 657: 658: `-m2' 659: `-m3' 660: These options are identical. Generate code for the ARM2 and ARM3 661: processors. This option is the default. You should also use this 662: option to generate code for ARM6 processors that are running with a 663: 26-bit program counter. 664: 665: `-m6' 666: Generate code for the ARM6 processor when running with a 32-bit 667: program counter. 668: 669: `-mapcs' 1.1.1.8 root 670: Generate a stack frame that is compliant with the ARM Procedure 1.1.1.7 root 671: Call Standard for all functions, even if this is not strictly 672: necessary for correct execution of the code. 673: 674: `-mbsd' 675: This option only applies to RISC iX. Emulate the native BSD-mode 676: compiler. This is the default if `-ansi' is not specified. 677: 678: `-mxopen' 679: This option only applies to RISC iX. Emulate the native 680: X/Open-mode compiler. 681: 682: `-mno-symrename' 683: This option only applies to RISC iX. Do not run the assembler 684: post-processor, `symrename', after code has been assembled. 685: Normally it is necessary to modify some of the standard symbols in 686: preparation for linking with the RISC iX C library; this option 687: suppresses this pass. The post-processor is never run when the 688: compiler is built for cross-compilation. 689: 690: 691: File: gcc.info, Node: M88K Options, Next: RS/6000 and PowerPC Options, Prev: ARM Options, Up: Submodel Options 692: 693: M88K Options 694: ------------ 695: 696: These `-m' options are defined for Motorola 88k architectures: 697: 698: `-m88000' 699: Generate code that works well on both the m88100 and the m88110. 700: 701: `-m88100' 702: Generate code that works best for the m88100, but that also runs 703: on the m88110. 704: 705: `-m88110' 706: Generate code that works best for the m88110, and may not run on 707: the m88100. 708: 709: `-mbig-pic' 710: Obsolete option to be removed from the next revision. Use `-fPIC'. 711: 712: `-midentify-revision' 713: Include an `ident' directive in the assembler output recording the 714: source file name, compiler name and version, timestamp, and 715: compilation flags used. 716: 717: `-mno-underscores' 718: In assembler output, emit symbol names without adding an underscore 719: character at the beginning of each name. The default is to use an 720: underscore as prefix on each name. 721: 722: `-mocs-debug-info' 723: `-mno-ocs-debug-info' 724: Include (or omit) additional debugging information (about 725: registers used in each stack frame) as specified in the 88open 726: Object Compatibility Standard, "OCS". This extra information 727: allows debugging of code that has had the frame pointer 728: eliminated. The default for DG/UX, SVr4, and Delta 88 SVr3.2 is 729: to include this information; other 88k configurations omit this 730: information by default. 731: 732: `-mocs-frame-position' 733: When emitting COFF debugging information for automatic variables 734: and parameters stored on the stack, use the offset from the 735: canonical frame address, which is the stack pointer (register 31) 736: on entry to the function. The DG/UX, SVr4, Delta88 SVr3.2, and 737: BCS configurations use `-mocs-frame-position'; other 88k 738: configurations have the default `-mno-ocs-frame-position'. 739: 740: `-mno-ocs-frame-position' 741: When emitting COFF debugging information for automatic variables 742: and parameters stored on the stack, use the offset from the frame 743: pointer register (register 30). When this option is in effect, 744: the frame pointer is not eliminated when debugging information is 745: selected by the -g switch. 746: 747: `-moptimize-arg-area' 748: `-mno-optimize-arg-area' 749: Control how function arguments are stored in stack frames. 750: `-moptimize-arg-area' saves space by optimizing them, but this 751: conflicts with the 88open specifications. The opposite 752: alternative, `-mno-optimize-arg-area', agrees with 88open 753: standards. By default GNU CC does not optimize the argument area. 754: 755: `-mshort-data-NUM' 756: Generate smaller data references by making them relative to `r0', 757: which allows loading a value using a single instruction (rather 758: than the usual two). You control which data references are 759: affected by specifying NUM with this option. For example, if you 760: specify `-mshort-data-512', then the data references affected are 761: those involving displacements of less than 512 bytes. 762: `-mshort-data-NUM' is not effective for NUM greater than 64k. 763: 764: `-mserialize-volatile' 765: `-mno-serialize-volatile' 766: Do, or don't, generate code to guarantee sequential consistency of 767: volatile memory references. By default, consistency is guaranteed. 768: 769: The order of memory references made by the MC88110 processor does 770: not always match the order of the instructions requesting those 771: references. In particular, a load instruction may execute before 772: a preceding store instruction. Such reordering violates 773: sequential consistency of volatile memory references, when there 774: are multiple processors. When consistency must be guaranteed, 775: GNU C generates special instructions, as needed, to force 776: execution in the proper order. 777: 778: The MC88100 processor does not reorder memory references and so 779: always provides sequential consistency. However, by default, GNU 780: C generates the special instructions to guarantee consistency even 781: when you use `-m88100', so that the code may be run on an MC88110 782: processor. If you intend to run your code only on the MC88100 783: processor, you may use `-mno-serialize-volatile'. 784: 785: The extra code generated to guarantee consistency may affect the 786: performance of your application. If you know that you can safely 787: forgo this guarantee, you may use `-mno-serialize-volatile'. 788: 789: `-msvr4' 790: `-msvr3' 791: Turn on (`-msvr4') or off (`-msvr3') compiler extensions related 792: to System V release 4 (SVr4). This controls the following: 793: 794: 1. Which variant of the assembler syntax to emit. 795: 796: 2. `-msvr4' makes the C preprocessor recognize `#pragma weak' 797: that is used on System V release 4. 798: 799: 3. `-msvr4' makes GNU CC issue additional declaration directives 800: used in SVr4. 801: 802: `-msvr4' is the default for the m88k-motorola-sysv4 and 803: m88k-dg-dgux m88k configurations. `-msvr3' is the default for all 804: other m88k configurations. 805: 806: `-mversion-03.00' 807: This option is obsolete, and is ignored. 808: 809: `-mno-check-zero-division' 810: `-mcheck-zero-division' 811: Do, or don't, generate code to guarantee that integer division by 812: zero will be detected. By default, detection is guaranteed. 813: 814: Some models of the MC88100 processor fail to trap upon integer 815: division by zero under certain conditions. By default, when 816: compiling code that might be run on such a processor, GNU C 817: generates code that explicitly checks for zero-valued divisors and 818: traps with exception number 503 when one is detected. Use of 819: mno-check-zero-division suppresses such checking for code 820: generated to run on an MC88100 processor. 821: 822: GNU C assumes that the MC88110 processor correctly detects all 823: instances of integer division by zero. When `-m88110' is 824: specified, both `-mcheck-zero-division' and 825: `-mno-check-zero-division' are ignored, and no explicit checks for 826: zero-valued divisors are generated. 827: 828: `-muse-div-instruction' 829: Use the div instruction for signed integer division on the MC88100 830: processor. By default, the div instruction is not used. 831: 832: On the MC88100 processor the signed integer division instruction 833: div) traps to the operating system on a negative operand. The 834: operating system transparently completes the operation, but at a 835: large cost in execution time. By default, when compiling code 836: that might be run on an MC88100 processor, GNU C emulates signed 837: integer division using the unsigned integer division instruction 838: divu), thereby avoiding the large penalty of a trap to the 839: operating system. Such emulation has its own, smaller, execution 840: cost in both time and space. To the extent that your code's 841: important signed integer division operations are performed on two 842: nonnegative operands, it may be desirable to use the div 843: instruction directly. 844: 845: On the MC88110 processor the div instruction (also known as the 846: divs instruction) processes negative operands without trapping to 847: the operating system. When `-m88110' is specified, 848: `-muse-div-instruction' is ignored, and the div instruction is used 849: for signed integer division. 850: 851: Note that the result of dividing INT_MIN by -1 is undefined. In 852: particular, the behavior of such a division with and without 853: `-muse-div-instruction' may differ. 854: 855: `-mtrap-large-shift' 856: `-mhandle-large-shift' 857: Include code to detect bit-shifts of more than 31 bits; 858: respectively, trap such shifts or emit code to handle them 859: properly. By default GNU CC makes no special provision for large 860: bit shifts. 861: 862: `-mwarn-passed-structs' 863: Warn when a function passes a struct as an argument or result. 864: Structure-passing conventions have changed during the evolution of 865: the C language, and are often the source of portability problems. 866: By default, GNU CC issues no such warning. 1.1.1.4 root 867: 868: 1.1.1.6 root 869: File: gcc.info, Node: RS/6000 and PowerPC Options, Next: RT Options, Prev: M88K Options, Up: Submodel Options 870: 871: IBM RS/6000 and PowerPC Options 872: ------------------------------- 873: 874: These `-m' options are defined for the IBM RS/6000 and PowerPC: 875: `-mpower' 876: `-mno-power' 877: `-mpower2' 878: `-mno-power2' 879: `-mpowerpc' 880: `-mno-powerpc' 1.1.1.7 root 881: `-mpowerpc-gpopt' 882: `-mno-powerpc-gpopt' 883: `-mpowerpc-gfxopt' 884: `-mno-powerpc-gfxopt' 1.1.1.6 root 885: GNU CC supports two related instruction set architectures for the 886: RS/6000 and PowerPC. The "POWER" instruction set are those 887: instructions supported by the `rios' chip set used in the original 888: RS/6000 systems and the "PowerPC" instruction set is the 889: architecture of the Motorola MPC6xx microprocessors. The PowerPC 890: architecture defines 64-bit instructions, but they are not 891: supported by any current processors. 892: 893: Neither architecture is a subset of the other. However there is a 894: large common subset of instructions supported by both. An MQ 895: register is included in processors supporting the POWER 896: architecture. 897: 898: You use these options to specify which instructions are available 899: on the processor you are using. The default value of these 900: options is determined when configuring GNU CC. Specifying the 901: `-mcpu=CPU_TYPE' overrides the specification of these options. We 902: recommend you use that option rather than these. 903: 904: The `-mpower' option allows GNU CC to generate instructions that 905: are found only in the POWER architecture and to use the MQ 906: register. Specifying `-mpower2' implies `-power' and also allows 907: GNU CC to generate instructions that are present in the POWER2 908: architecture but not the original POWER architecture. 909: 910: The `-mpowerpc' option allows GNU CC to generate instructions that 911: are found only in the 32-bit subset of the PowerPC architecture. 1.1.1.7 root 912: Specifying `-mpowerpc-gpopt' implies `-mpowerpc' and also allows 913: GNU CC to use the optional PowerPC architecture instructions in the 914: General Purpose group, including floating-point square root. 915: Specifying `-mpowerpc-gfxopt' implies `-mpowerpc' and also allows 916: GNU CC to use the optional PowerPC architecture instructions in 917: the Graphics group, including floating-point select. 1.1.1.6 root 918: 919: If you specify both `-mno-power' and `-mno-powerpc', GNU CC will 920: use only the instructions in the common subset of both 1.1.1.7 root 921: architectures plus some special AIX common-mode calls, and will 922: not use the MQ register. Specifying both `-mpower' and `-mpowerpc' 923: permits GNU CC to use any instruction from either architecture and 924: to allow use of the MQ register; specify this for the Motorola 925: MPC601. 1.1.1.6 root 926: 927: `-mnew-mnemonics' 928: `-mold-mnemonics' 929: Select which mnemonics to use in the generated assembler code. 930: `-mnew-mnemonics' requests output that uses the assembler mnemonics 931: defined for the PowerPC architecture, while `-mold-mnemonics' 932: requests the assembler mnemonics defined for the POWER 933: architecture. Instructions defined in only one architecture have 934: only one mnemonic; GNU CC uses that mnemonic irrespective of which 1.1.1.8 root 935: of these options is specified. 1.1.1.6 root 936: 937: PowerPC assemblers support both the old and new mnemonics, as will 938: later POWER assemblers. Current POWER assemblers only support the 939: old mnemonics. Specify `-mnew-mnemonics' if you have an assembler 940: that supports them, otherwise specify `-mold-mnemonics'. 941: 942: The default value of these options depends on how GNU CC was 1.1.1.8 root 943: configured. Specifying `-mcpu=CPU_TYPE' sometimes overrides the 1.1.1.7 root 944: value of these option. Unless you are building a cross-compiler, 1.1.1.6 root 945: you should normally not specify either `-mnew-mnemonics' or 946: `-mold-mnemonics', but should instead accept the default. 947: 948: `-mcpu=CPU_TYPE' 949: Set architecture type, register usage, choice of mnemonics, and 950: instruction scheduling parameters for machine type CPU_TYPE. By 951: default, CPU_TYPE is the target system defined when GNU CC was 952: configured. Supported values for CPU_TYPE are `rios1', `rios2', 1.1.1.8 root 953: `rsc', `601', `603', `604', `power', `powerpc', `403', and 954: `common'. `-mcpu=power' and `-mcpu=powerpc' specify generic POWER 955: and pure PowerPC (i.e., not MPC601) architecture machine types, 956: with an appropriate, generic processor model assumed for 957: scheduling purposes. 1.1.1.7 root 958: 959: Specifying `-mcpu=rios1', `-mcpu=rios2', `-mcpu=rsc', or 960: `-mcpu=power' enables the `-mpower' option and disables the 961: `-mpowerpc' option; `-mcpu=601' enables both the `-mpower' and 1.1.1.8 root 962: `-mpowerpc' options; `-mcpu=603', `-mcpu=604', `-mcpu=403', and 963: `-mcpu=powerpc' enable the `-mpowerpc' option and disable the 964: `-mpower' option; `-mcpu=common' disables both the `-mpower' and 965: `-mpowerpc' options. 1.1.1.6 root 966: 967: To generate code that will operate on all members of the RS/6000 1.1.1.7 root 968: and PowerPC families, specify `-mcpu=common'. In that case, GNU CC 969: will use only the instructions in the common subset of both 970: architectures plus some special AIX common-mode calls, and will 971: not use the MQ register. GNU CC assumes a generic processor model 972: for scheduling purposes. 973: 974: Specifying `-mcpu=rios1', `-mcpu=rios2', `-mcpu=rsc', or 975: `-mcpu=power' also disables the `new-mnemonics' option. 1.1.1.8 root 976: Specifying `-mcpu=601', `-mcpu=603', `-mcpu=604', `403', or 1.1.1.7 root 977: `-mcpu=powerpc' also enables the `new-mnemonics' option. 1.1.1.6 root 978: 1.1.1.7 root 979: `-mfull-toc' 1.1.1.6 root 980: `-mno-fp-in-toc' 1.1.1.7 root 981: `-mno-sum-in-toc' 1.1.1.6 root 982: `-mminimal-toc' 983: Modify generation of the TOC (Table Of Contents), which is created 1.1.1.7 root 984: for every executable file. The `-mfull-toc' option is selected by 985: default. In that case, GNU CC will allocate at least one TOC 1.1.1.6 root 986: entry for each unique non-automatic variable reference in your 987: program. GNU CC will also place floating-point constants in the 1.1.1.7 root 988: TOC. However, only 16,384 entries are available in the TOC. 1.1.1.6 root 989: 1.1.1.7 root 990: If you receive a linker error message that saying you have 991: overflowed the available TOC space, you can reduce the amount of 992: TOC space used with the `-mno-fp-in-toc' and `-mno-sum-in-toc' 993: options. `-mno-fp-in-toc' prevents GNU CC from putting 994: floating-point constants in the TOC and `-mno-sum-in-toc' forces 995: GNU CC to generate code to calculate the sum of an address and a 996: constant at run-time instead of putting that sum into the TOC. 997: You may specify one or both of these options. Each causes GNU CC 998: to produce very slightly slower and larger code at the expense of 999: conserving TOC space. 1000: 1001: If you still run out of space in the TOC even when you specify 1002: both of these options, specify `-mminimal-toc' instead. This 1003: option causes GNU CC to make only one TOC entry for every file. 1004: When you specify this option, GNU CC will produce code that is 1005: slower and larger but which uses extremely little TOC space. You 1006: may wish to use this option only on files that contain less 1007: frequently executed code. 1.1.1.6 root 1008: 1.1.1.8 root 1009: `-msoft-float' 1010: `-mhard-float' 1011: Generate code that does not use (uses) the floating-point register 1012: set. Software floating point emulation is provided if you use the 1013: `-msoft-float' option, and pass the option to GNU CC when linking. 1014: 1015: `-mmultiple' 1016: `-mno-multiple' 1017: Generate code that uses (does not use) the load multiple word 1018: instructions and the store multiple word instructions. These 1019: instructions are generated by default on POWER systems, and not 1020: generated on PowerPC systems. Do not use `-mmultiple' on little 1021: endian PowerPC systems, since those instructions do not work when 1022: the processor is in little endian mode. 1023: 1024: `-mstring' 1025: `-mno-string' 1026: Generate code that uses (does not use) the load string 1027: instructions and the store string word instructions to save 1028: multiple registers and do small block moves. These instructions 1029: are generated by default on POWER systems, anod not generated on 1030: PowerPC systems. Do not use `-mstring' on little endian PowerPC 1031: systems, since those instructions do not work when the processor 1032: is in little endian mode. 1033: 1034: `-mno-bit-align' 1035: `-mbit-align' 1036: On System V.4 and embedded PowerPC systems do not (do) force 1037: structures and unions that contain bit fields to be aligned to the 1038: base type of the bit field. 1039: 1040: For example, by default a structure containing nothing but 8 1041: `unsigned' bitfields of length 1 would be aligned to a 4 byte 1042: boundary and have a size of 4 bytes. By using `-mno-bit-align', 1043: the structure would be aligned to a 1 byte boundary and be one 1044: byte in size. 1045: 1046: `-mno-strict-align' 1047: `-mstrict-align' 1048: On System V.4 and embedded PowerPC systems do not (do) assume that 1049: unaligned memory references will be handled by the system. 1050: 1051: `-mrelocatable' 1052: `-mno-relocatable' 1053: On embedded PowerPC systems generate code that allows (does not 1054: allow) the program to be relocated to a different address at 1055: runtime. 1056: 1057: `-mno-toc' 1058: `-mtoc' 1059: On System V.4 and embedded PowerPC systems do not (do) assume that 1060: register 2 contains a pointer to a global area pointing to the 1061: addresses used in the program. 1062: 1063: `-mno-traceback' 1064: `-mtraceback' 1065: On embedded PowerPC systems do not (do) generate a traceback tag 1066: before the start of the function. This tag can be used by the 1067: debugger to identify where the start of a function is. 1068: 1069: `-mlittle' 1070: `-mlittle-endian' 1071: On System V.4 and embedded PowerPC systems compile code for the 1072: processor in little endian mode. The `-mlittle-endian' option is 1073: the same as `-mlittle'. 1074: 1075: `-mbig' 1076: `-mbig-endian' 1077: On System V.4 and embedded PowerPC systems compile code for the 1078: processor in big endian mode. The `-mbig-endian' option is the 1079: same as `-mbig'. 1080: 1081: `-mcall-sysv' 1082: On System V.4 and embedded PowerPC systems compile code using 1083: calling conventions that adheres to the March 1995 draft of the 1084: System V Application Binary Interface, PowerPC processor 1085: supplement. This is the default unless you configured GCC using 1086: `powerpc-*-eabiaix'. 1087: 1088: `-mcall-aix' 1089: On System V.4 and embedded PowerPC systems compile code using 1090: calling conventions that are similar to those used on AIX. This 1091: is the default if you configured GCC using `powerpc-*-eabiaix'. 1092: 1093: `-mprototype' 1094: `-mno-prototype' 1095: On System V.4 and embedded PowerPC systems assume that all calls to 1096: variable argument functions are properly prototyped. Otherwise, 1097: the compiler must insert an instruction before every non 1098: prototyped call to set or clear bit 6 of the condition code 1099: register (CR) to indicate whether floating point values were 1100: passed in the floating point registers in case the function takes 1101: a variable arguments. With `-mprototype', only calls to 1102: prototyped variable argument functions will set or clear the bit. 1103: 1.1.1.6 root 1104: 1105: File: gcc.info, Node: RT Options, Next: MIPS Options, Prev: RS/6000 and PowerPC Options, Up: Submodel Options 1106: 1107: IBM RT Options 1108: -------------- 1109: 1110: These `-m' options are defined for the IBM RT PC: 1111: 1112: `-min-line-mul' 1113: Use an in-line code sequence for integer multiplies. This is the 1114: default. 1115: 1116: `-mcall-lib-mul' 1117: Call `lmul$$' for integer multiples. 1118: 1119: `-mfull-fp-blocks' 1120: Generate full-size floating point data blocks, including the 1121: minimum amount of scratch space recommended by IBM. This is the 1122: default. 1123: 1124: `-mminimum-fp-blocks' 1125: Do not include extra scratch space in floating point data blocks. 1126: This results in smaller code, but slower execution, since scratch 1127: space must be allocated dynamically. 1128: 1129: `-mfp-arg-in-fpregs' 1130: Use a calling sequence incompatible with the IBM calling 1131: convention in which floating point arguments are passed in 1132: floating point registers. Note that `varargs.h' and `stdargs.h' 1133: will not work with floating point operands if this option is 1134: specified. 1135: 1136: `-mfp-arg-in-gregs' 1137: Use the normal calling convention for floating point arguments. 1138: This is the default. 1139: 1140: `-mhc-struct-return' 1141: Return structures of more than one word in memory, rather than in a 1142: register. This provides compatibility with the MetaWare HighC (hc) 1143: compiler. Use the option `-fpcc-struct-return' for compatibility 1144: with the Portable C Compiler (pcc). 1145: 1146: `-mnohc-struct-return' 1147: Return some structures of more than one word in registers, when 1148: convenient. This is the default. For compatibility with the 1149: IBM-supplied compilers, use the option `-fpcc-struct-return' or the 1150: option `-mhc-struct-return'. 1151:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.