| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| NNNNAAAAMMMMEEEE |
| gcc, g++ - GNU project C and C++ Compiler (v2 preliminary) |
| |
| SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS |
| gcc [[[[_o_p_t_i_o_n | _f_i_l_e_n_a_m_e ]... |
| g++ [[[[_o_p_t_i_o_n | _f_i_l_e_n_a_m_e ]... |
| |
| WWWWAAAARRRRNNNNIIIINNNNGGGG |
| The information in this man page is an extract from the full |
| documentation of the GNU C compiler, and is limited to the |
| meaning of the options. This man page is not kept up to |
| date except when volunteers want to maintain it. |
| |
| For complete and current documentation, refer to the Info |
| file `ggggcccccccc' or the manual _U_s_i_n_g _a_n_d _P_o_r_t_i_n_g _G_N_U _C_C (_f_o_r _v_e_r_- |
| _s_i_o_n _2._0). Both are made from the Texinfo source file |
| ggggcccccccc....tttteeeexxxxiiiinnnnffffoooo. |
| |
| DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN |
| The C and C++ compilers are integrated. Both process input |
| files through one or more of four stages: preprocessing, |
| compilation, assembly, and linking. Source filename suf- |
| fixes identify the source language, but which name you use |
| for the compiler governs default assumptions: |
| |
| ggggcccccccc assumes preprocessed (....iiii) files are C and assumes C |
| style linking. |
| |
| gggg++++++++ assumes preprocessed (....iiii) files are C++ and assumes C++ |
| style linking. |
| |
| Suffixes of source file names indicate the language and kind |
| of processing to be done: |
| |
| ....cccc C source; preprocess, compile, assemble |
| ....CCCC C++ source; preprocess, compile, assemble |
| ....cccccccc C++ source; preprocess, compile, assemble |
| ....ccccxxxxxxxx C++ source; preprocess, compile, assemble |
| ....mmmm Objective-C source; preprocess, compile, assemble |
| ....iiii preprocessed C; compile, assemble |
| ....iiiiiiii preprocessed C++; compile, assemble |
| ....ssss Assembler source; assemble |
| ....SSSS Assembler source; preprocess, assemble |
| ....hhhh Preprocessor file; not usually named on command line |
| |
| ?? Other (unrecognized) files passed to linker. |
| Common cases: |
| ....oooo Object file |
| ....aaaa Archive file |
| |
| Linking is always the last stage unless you use one of the ---- |
| cccc, ---- SSSS, or ----EEEE options to avoid it (or unless compilation |
| |
| |
| |
| GNU Tools Last change: 28may1992 1 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| errors stop the whole process). For the link stage, all ....oooo |
| files corresponding to source files, ----llll libraries, unrecog- |
| nized filenames (including named ....oooo object files and ....aaaa |
| archives) are passed to the linker in command-line order. |
| |
| |
| OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| Options must be separate: `----ddddrrrr' is quite different from `---- dddd |
| ----rrrr '. |
| |
| Most `----ffff' and `----WWWW' options have two contrary forms: ---- ffff_n_a_m_e |
| and ---- ffffnnnnoooo ---- _n_a_m_e (or ----WWWW_n_a_m_e and ----WWWWnnnnoooo----_n_a_m_e). Only the non- |
| default forms are shown here. |
| |
| Here is a summary of all the options, grouped by type. |
| Explanations are in the following sections. |
| |
| |
| OOOOvvvveeeerrrraaaallllllll OOOOppppttttiiiioooonnnnssss |
| -c -S -E -o _f_i_l_e -pipe -v -x _l_a_n_g_u_a_g_e |
| |
| |
| LLLLaaaannnngggguuuuaaaaggggeeee OOOOppppttttiiiioooonnnnssss |
| -ansi -fall-virtual -fcond-mismatch -fdollars-in- |
| identifiers -fenum-int-equiv -fno-asm -fno-builtin -fno |
| -strict-prototype -fsigned-bitfields -fsigned-char - |
| fthis-is-variable -funsigned-bitfields -funsigned-char |
| -fwritable-strings -traditional -traditional-cpp - |
| trigraphs |
| |
| |
| WWWWaaaarrrrnnnniiiinnnngggg OOOOppppttttiiiioooonnnnssss |
| -fsyntax-only -pedantic -pedantic-errors -w -W -Wall - |
| Waggregate-return -Wcast-align -Wcast-qual -Wcomment - |
| Wconversion -Wenum-clash -Werror -Wformat -Wid-clash- |
| _l_e_n -Wimplicit -Winline -Wmissing-prototypes - |
| Wparentheses -Wpointer-arith -Wreturn-type -Wshadow - |
| Wstrict-prototypes -Wswitch -Wtraditional -Wtrigraphs - |
| Wuninitialized -Wunused -Wwrite-strings |
| |
| |
| DDDDeeeebbbbuuuuggggggggiiiinnnngggg OOOOppppttttiiiioooonnnnssss |
| -a -d_l_e_t_t_e_r_s -fpretend-float -g -gstabs -gdwarf -ggdb - |
| gsdb -p -pg -save-temps |
| |
| |
| OOOOppppttttiiiimmmmiiiizzzzaaaattttiiiioooonnnn OOOOppppttttiiiioooonnnnssss |
| -fcaller-saves -fcse-follow-jumps -fdelayed-branch - |
| felide-constructors -fexpensive-optimizations -ffloat- |
| store -fforce-addr -fforce-mem -finline -finline- |
| functions -fkeep-inline-functions -fmemoize-lookups - |
| fno-default-inline -fno-defer-pop -fno-function-cse - |
| |
| |
| |
| GNU Tools Last change: 28may1992 2 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| fomit-frame-pointer -frerun-cse-after-loop -fschedule- |
| insns -fschedule-insns2 -fstrength-reduce -fthread- |
| jumps -funroll-all-loops -funroll-loops -O -O2 |
| |
| |
| PPPPrrrreeeepppprrrroooocccceeeessssssssoooorrrr OOOOppppttttiiiioooonnnnssss |
| -C -dD -dM -dN -D_m_a_c_r_o[=_d_e_f_n] -E -H -i _f_i_l_e -M -MD -MM |
| -MMD -nostdinc -P -U_m_a_c_r_o -undef |
| |
| |
| LLLLiiiinnnnkkkkeeeerrrr OOOOppppttttiiiioooonnnnssss |
| -l_l_i_b_r_a_r_y -nostdlib -static |
| |
| |
| DDDDiiiirrrreeeeccccttttoooorrrryyyy OOOOppppttttiiiioooonnnnssss |
| -B_p_r_e_f_i_x -I_d_i_r -I- -L_d_i_r |
| |
| |
| TTTTaaaarrrrggggeeeetttt OOOOppppttttiiiioooonnnnssss |
| -b _m_a_c_h_i_n_e -V _v_e_r_s_i_o_n |
| |
| |
| MMMMaaaacccchhhhiiiinnnneeee DDDDeeeeppppeeeennnnddddeeeennnntttt OOOOppppttttiiiioooonnnnssss |
| _M_6_8_0_x_0 _O_p_t_i_o_n_s |
| -m68000 -m68020 -m68881 -mbitfield -mc68000 -mc68020 - |
| mfpa -mnobitfield -mrtd -mshort -msoft-float |
| |
| _V_A_X _O_p_t_i_o_n_s |
| -mg -mgnu -munix |
| |
| _S_P_A_R_C _O_p_t_i_o_n_s |
| -mfpu -mno-epilogue |
| |
| _C_o_n_v_e_x _O_p_t_i_o_n_s |
| -margcount -mc1 -mc2 -mnoargcount |
| |
| _A_M_D_2_9_K _O_p_t_i_o_n_s |
| -m29000 -m29050 -mbw -mdw -mkernel-registers -mlarge - |
| mnbw -mnodw -msmall -mstack-check -muser-registers |
| |
| _M_8_8_K _O_p_t_i_o_n_s |
| -mbig-pic -mcheck-zero-division -mhandle-large-shift - |
| midentify-revision -mno-check-zero-division -mno-ocs- |
| debug-info -mno-ocs-frame-position -mno-optimize-arg- |
| area -mno-underscores -mocs-debug-info -mocs-frame- |
| position -moptimize-arg-area -mshort-data-_n_u_m -msvr3 - |
| msvr4 -mtrap-large-shift -muse-div-instruction - |
| mversion-03.00 -mwarn-passed-structs |
| |
| _R_S_6_0_0_0 _O_p_t_i_o_n_s |
| -mfp-in-toc -mno-fop-in-toc |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 3 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| _R_T _O_p_t_i_o_n_s |
| -mcall-lib-mul -mfp-arg-in-fpregs -mfp-arg-in-gregs - |
| mfull-fp-blocks -mhc-struct-return -min-line-mul - |
| mminimum-fp-blocks -mnohc-struct-return |
| |
| _M_I_P_S _O_p_t_i_o_n_s |
| -mcpu=_c_p_u _t_y_p_e -mips2 -mips3 -mint64 -mlong64 - |
| mlonglong128 -mmips-as -mgas -mrnames -mno-rnames - |
| mgpopt -mno-gpopt -mstats -mno-stats -mmemcpy -mno- |
| memcpy -mno-mips-tfile -mmips-tfile -msoft-float -mhard |
| -float -mabicalls -mno-abicalls -mhalf-pic -mno-half- |
| pic -G _n_u_m |
| |
| _i_3_8_6 _O_p_t_i_o_n_s |
| -m486 -mno486 -msoft-float |
| |
| |
| CCCCooooddddeeee GGGGeeeennnneeeerrrraaaattttiiiioooonnnn OOOOppppttttiiiioooonnnnssss |
| +e_N -fcall-saved-_r_e_g -fcall-used-_r_e_g -ffixed-_r_e_g -fno- |
| common -fno-gnu-binutils -fnonnull-objects -fpcc-struct |
| -return -fpic -fPIC -fshared-data -fshort-enums -fshort |
| -double -fvolatile |
| |
| |
| OOOOVVVVEEEERRRRAAAALLLLLLLL OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| ----xxxx _l_a_n_g_u_a_g_e |
| Specify explicitly the _l_a_n_g_u_a_g_e for the following input |
| files (rather than choosing a default based on the file |
| name suffix) . This option applies to all following |
| input files until the next ` ----xxxx' option. Possible |
| values of _l_a_n_g_u_a_g_e are `cccc', `oooobbbbjjjjeeeeccccttttiiiivvvveeee----cccc', `cccc---- hhhheeeeaaaaddddeeeerrrr', |
| `cccc++++++++', `ccccpppppppp----oooouuuuttttppppuuuutttt', `aaaasssssssseeeemmmmbbbblllleeeerrrr', and `aaaasssssssseeeemmmmbbbblllleeeerrrr----wwwwiiiitttthhhh---- |
| ccccpppppppp'. |
| |
| ----xxxx nnnnoooonnnneeee |
| Turn off any specification of a language, so that sub- |
| sequent files are handled according to their file name |
| suffixes (as they are if `----xxxx' has not been used at |
| all). |
| |
| If you want only some of the four stages (preprocess, com- |
| pile, assemble, link), you can use `----xxxx' (or filename suf- |
| fixes) to tell ggggcccccccc where to start, and one of the options `---- |
| cccc', ` ---- SSSS', or `----EEEE' to say where ggggcccccccc is to stop. Note that |
| some combinations (for example, `----xxxx ccccpppppppp----oooouuuuttttppppuuuutttt ----EEEE') instruct |
| ggggcccccccc to do nothing at all. |
| |
| ----cccc Compile or assemble the source files, but do not link. |
| The compiler output is an object file corresponding to |
| each source file. |
| |
| By default, GCC makes the object file name for a source |
| |
| |
| |
| GNU Tools Last change: 28may1992 4 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| file by replacing the suffix `....cccc', `....iiii', `....ssss', etc., |
| with `....oooo'. Use ----oooo to select another name. |
| |
| GCC ignores any unrecognized input files (those that do |
| not require compilation or assembly) with the ----cccc op- |
| tion. |
| |
| ----SSSS Stop after the stage of compilation proper; do not as- |
| semble. The output is an assembler code file for each |
| non-assembler input file specified. |
| |
| By default, GCC makes the assembler file name for a |
| source file by replacing the suffix `....cccc', `....iiii', etc., |
| with `....ssss'. Use ----oooo to select another name. |
| |
| |
| GCC ignores any input files that don't require compila- |
| tion. |
| |
| ----EEEE Stop after the preprocessing stage; do not run the |
| compiler proper. The output is preprocessed source |
| code, which is sent to the standard output. |
| |
| GCC ignores input files which don't require preprocess- |
| ing. |
| |
| ----oooo _f_i_l_e |
| Place output in file _f_i_l_e. This applies regardless to |
| whatever sort of output GCC is producing, whether it be |
| an executable file, an object file, an assembler file |
| or preprocessed C code. |
| |
| Since only one output file can be specified, it does |
| not make sense to use `----oooo' when compiling more than one |
| input file, unless you are producing an executable file |
| as output. |
| |
| If you do not specify `----oooo', the default is to put an |
| executable file in `aaaa....oooouuuutttt', the object file for |
| `_s_o_u_r_c_e._s_u_f_f_i_x' in `_s_o_u_r_c_e.o', its assembler file in |
| `_s_o_u_r_c_e.s', and all preprocessed C source on standard |
| output. |
| |
| ----vvvv Print (on standard error output) the commands executed |
| to run the stages of compilation. Also print the ver- |
| sion number of the compiler driver program and of the |
| preprocessor and the compiler proper. |
| |
| ----ppppiiiippppeeee |
| Use pipes rather than temporary files for communication |
| between the various stages of compilation. This fails |
| to work on some systems where the assembler cannot read |
| |
| |
| |
| GNU Tools Last change: 28may1992 5 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| from a pipe; but the GNU assembler has no trouble. |
| |
| LLLLAAAANNNNGGGGUUUUAAAAGGGGEEEE OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| The following options control the dialect of C that the com- |
| piler accepts: |
| |
| ----aaaannnnssssiiii |
| _S_u_p_p_o_r_t _a_l_l _A_N_S_I _s_t_a_n_d_a_r_d _C _p_r_o_g_r_a_m_s. |
| |
| _T_h_i_s _t_u_r_n_s _o_f_f _c_e_r_t_a_i_n _f_e_a_t_u_r_e_s _o_f _G_N_U _C _t_h_a_t _a_r_e _i_n_- |
| _c_o_m_p_a_t_i_b_l_e _w_i_t_h ANSI C, such as the aaaassssmmmm, iiiinnnnlllliiiinnnneeee and |
| ttttyyyyppppeeeeooooffff keywords, and predefined macros such as uuuunnnniiiixxxx and |
| vvvvaaaaxxxx that identify the type of system you are using. It |
| also enables the undesirable and rarely used ANSI tri- |
| graph feature, and makes the preprocessor accept `$$$$' as |
| part of identifiers. |
| |
| The alternate keywords ________aaaassssmmmm________, ________eeeexxxxtttteeeennnnssssiiiioooonnnn________, ________iiiinnnn---- |
| lllliiiinnnneeee________ and ________ttttyyyyppppeeeeooooffff________ continue to work despite `----aaaannnnssssiiii'. |
| You would not want to use them in an ANSI C program, of |
| course, but it is useful to put them in header files |
| that might be included in compilations done with ` ---- |
| aaaannnnssssiiii'. Alternate predefined macros such as ________uuuunnnniiiixxxx________ |
| and ________vvvvaaaaxxxx________ are also available, with or without ` ---- |
| aaaannnnssssiiii'. |
| |
| The `----aaaannnnssssiiii' option does not cause non-ANSI programs to |
| be rejected gratuitously. For that, `----ppppeeeeddddaaaannnnttttiiiicccc' is re- |
| quired in addition to `----aaaannnnssssiiii'. |
| |
| The preprocessor predefines a macro ________SSSSTTTTRRRRIIIICCCCTTTT____AAAANNNNSSSSIIII________ |
| when you use the `----aaaannnnssssiiii' option. Some header files may |
| notice this macro and refrain from declaring certain |
| functions or defining certain macros that the ANSI |
| standard doesn't call for; this is to avoid interfering |
| with any programs that might use these names for other |
| things. |
| |
| ----ffffnnnnoooo----aaaassssmmmm |
| Do not recognize aaaassssmmmm, iiiinnnnlllliiiinnnneeee or ttttyyyyppppeeeeooooffff as a keyword. |
| These words may then be used as identifiers. You can |
| use ________aaaassssmmmm________, ________iiiinnnnlllliiiinnnneeee________ and ________ttttyyyyppppeeeeooooffff________ instead. ` ---- |
| aaaannnnssssiiii' implies `----ffffnnnnoooo----aaaassssmmmm'. |
| |
| ----ffffnnnnoooo----bbbbuuuuiiiillllttttiiiinnnn |
| (_I_g_n_o_r_e_d _f_o_r _C++.) Don't recognize non-ANSI built-in |
| functions. ` ---- aaaannnnssssiiii' also has this effect. Currently, |
| the only function affected is aaaallllllllooooccccaaaa. |
| |
| ----ffffnnnnoooo----ssssttttrrrriiiicccctttt----pppprrrroooottttoooottttyyyyppppeeee |
| (_C++ _o_n_l_y.) Consider the declaration iiiinnnntttt ffffoooooooo (((())));;;;. In |
| C++, this means that the function ffffoooooooo takes no argu- |
| |
| |
| |
| GNU Tools Last change: 28may1992 6 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ments. |
| In ANSI C, this is declared iiiinnnntttt ffffoooooooo((((vvvvooooiiiidddd))));;;;. With the |
| flag `----ffffnnnnoooo----ssssttttrrrriiiicccctttt----pppprrrroooottttoooottttyyyyppppeeee', declaring functions with |
| no arguments is equivalent to declaring its argument |
| list to be untyped, i.e., iiiinnnntttt ffffoooooooo (((())));;;; is equivalent to |
| saying iiiinnnntttt ffffoooooooo ((((............))));;;;. |
| |
| ----ttttrrrriiiiggggrrrraaaapppphhhhssss |
| Support ANSI C trigraphs. The `----aaaannnnssssiiii' option implies ` |
| ----ttttrrrriiiiggggrrrraaaapppphhhhssss'. |
| |
| ----ttttrrrraaaaddddiiiittttiiiioooonnnnaaaallll |
| Attempt to support some aspects of traditional C com- |
| pilers. For details, see the GNU C Manual; the dupli- |
| cate list here has been deleted so that we won't get |
| complaints when it is out of date. |
| |
| But one note about C++ programs only (not C). `----ttttrrrraaaaddddiiii---- |
| ttttiiiioooonnnnaaaallll' has one additional effect for C++: assignment |
| to tttthhhhiiiissss is permitted. This is the same as the effect |
| of `----fffftttthhhhiiiissss----iiiissss----vvvvaaaarrrriiiiaaaabbbblllleeee'. |
| |
| ----ttttrrrraaaaddddiiiittttiiiioooonnnnaaaallll----ccccpppppppp |
| Attempt to support some aspects of traditional C |
| preprocessors. This includes the items that specifi- |
| cally mention the preprocessor above, but none of the |
| other effects of `----ttttrrrraaaaddddiiiittttiiiioooonnnnaaaallll'. |
| |
| ----ffffddddoooollllllllaaaarrrrssss----iiiinnnn----iiiiddddeeeennnnttttiiiiffffiiiieeeerrrrssss |
| (_C++ _o_n_l_y.) Permit the use of `$$$$' in identifiers. |
| (For GNU C, this is the default, and you can forbid it |
| with `----aaaannnnssssiiii'.) Traditional C allowed the character `$$$$' |
| to form part of identifiers; by default, GNU C also al- |
| lows this. However, ANSI C forbids `$$$$' in identifiers, |
| and GNU C++ also forbids it by default on most plat- |
| forms (though on some platforms it's enabled by default |
| for GNU C++ as well). |
| |
| ----ffffeeeennnnuuuummmm----iiiinnnntttt----eeeeqqqquuuuiiiivvvv |
| (_C++ _o_n_l_y.) Normally GNU C++ allows conversion of eeeennnnuuuummmm |
| to iiiinnnntttt, but not the other way around. Use this option |
| if you want GNU C++ to allow conversion of iiiinnnntttt to eeeennnnuuuummmm |
| as well. |
| |
| ----ffffaaaallllllll----vvvviiiirrrrttttuuuuaaaallll |
| (_C++ _o_n_l_y.) When you use the ` ---- ffffaaaallllllll ---- vvvviiiirrrrttttuuuuaaaallll', all |
| member functions (except for constructor functions and |
| new/delete member operators) declared in the same class |
| with a ``method-call'' operator method are treated as |
| virtual functions of the given class. In effect, all |
| of these methods become ``implicitly virtual.'' |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 7 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| This does _n_o_t mean that all calls to these methods will |
| be made through the internal table of virtual func- |
| tions. There are some circumstances under which it is |
| obvious that a call to a given virtual function can be |
| made directly, and in these cases the calls still go |
| direct. |
| |
| The effect of making all methods of a class with a de- |
| clared `ooooppppeeeerrrraaaattttoooorrrr---->>>>(((())))(((())))' implicitly virtual using `----ffffaaaallllllll |
| ----vvvviiiirrrrttttuuuuaaaallll' extends also to all non-constructor methods |
| of any class derived from such a class. |
| |
| ----ffffccccoooonnnndddd----mmmmiiiissssmmmmaaaattttcccchhhh |
| Allow conditional expressions with mismatched types in |
| the second and third arguments. The value of such an |
| expression is void. |
| |
| ----fffftttthhhhiiiissss----iiiissss----vvvvaaaarrrriiiiaaaabbbblllleeee |
| (_C++ _o_n_l_y.) The incorporation of user-defined free |
| store management into C++ has made assignment to tttthhhhiiiissss |
| an anachronism. Therefore, by default GNU C++ treats |
| the type of tttthhhhiiiissss in a member function of ccccllllaaaassssssss XXXX to be |
| XXXX ****ccccoooonnnnsssstttt. In other words, it is illegal to assign to |
| tttthhhhiiiissss within a class member function. However, for |
| backwards compatibility, you can invoke the old |
| behavior by using `----fffftttthhhhiiiissss----iiiissss----vvvvaaaarrrriiiiaaaabbbblllleeee'. |
| |
| ----ffffuuuunnnnssssiiiiggggnnnneeeedddd----cccchhhhaaaarrrr |
| Let the type cccchhhhaaaarrrr be unsigned, like uuuunnnnssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr. |
| |
| Each kind of machine has a default for what cccchhhhaaaarrrr should |
| be. It is either like uuuunnnnssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr by default or like |
| ssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr by default. |
| |
| Ideally, a portable program should always use ssssiiiiggggnnnneeeedddd |
| cccchhhhaaaarrrr or uuuunnnnssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr when it depends on the signedness |
| of an object. But many programs have been written to |
| use plain cccchhhhaaaarrrr and expect it to be signed, or expect it |
| to be unsigned, depending on the machines they were |
| written for. This option, and its inverse, let you |
| make such a program work with the opposite default. |
| |
| The type cccchhhhaaaarrrr is always a distinct type from each of |
| ssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr and uuuunnnnssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr, even though its behavior |
| is always just like one of those two. |
| |
| |
| ----ffffssssiiiiggggnnnneeeedddd----cccchhhhaaaarrrr |
| Let the type cccchhhhaaaarrrr be signed, like ssssiiiiggggnnnneeeedddd cccchhhhaaaarrrr. |
| |
| Note that this is equivalent to `----ffffnnnnoooo----uuuunnnnssssiiiiggggnnnneeeedddd ---- cccchhhhaaaarrrr', |
| which is the negative form of `----ffffuuuunnnnssssiiiiggggnnnneeeedddd----cccchhhhaaaarrrr'. Like- |
| |
| |
| |
| GNU Tools Last change: 28may1992 8 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| wise, `----ffffnnnnoooo----ssssiiiiggggnnnneeeedddd----cccchhhhaaaarrrr' is equivalent to `----ffffuuuunnnnssssiiiiggggnnnneeeedddd ---- |
| cccchhhhaaaarrrr'. |
| |
| ----ffffssssiiiiggggnnnneeeedddd----bbbbiiiittttffffiiiieeeellllddddssss |
| |
| ----ffffuuuunnnnssssiiiiggggnnnneeeedddd----bbbbiiiittttffffiiiieeeellllddddssss |
| |
| ----ffffnnnnoooo----ssssiiiiggggnnnneeeedddd----bbbbiiiittttffffiiiieeeellllddddssss |
| |
| ----ffffnnnnoooo----uuuunnnnssssiiiiggggnnnneeeedddd----bbbbiiiittttffffiiiieeeellllddddssss |
| These options control whether a bitfield is signed or |
| unsigned, when declared with no explicit `ssssiiiiggggnnnneeeedddd' or |
| `uuuunnnnssssiiiiggggnnnneeeedddd' qualifier. By default, such a bitfield is |
| signed, because this is consistent: the basic integer |
| types such as iiiinnnntttt are signed types. |
| |
| However, when you specify `----ttttrrrraaaaddddiiiittttiiiioooonnnnaaaallll', bitfields are |
| all unsigned no matter what. |
| |
| ----ffffwwwwrrrriiiittttaaaabbbblllleeee----ssssttttrrrriiiinnnnggggssss |
| Store string constants in the writable data segment and |
| don't uniquize them. This is for compatibility with |
| old programs which assume they can write into string |
| constants. `----ttttrrrraaaaddddiiiittttiiiioooonnnnaaaallll' also has this effect. |
| |
| Writing into string constants is a very bad idea; |
| ``constants'' should be constant. |
| |
| PPPPRRRREEEEPPPPRRRROOOOCCCCEEEESSSSSSSSOOOORRRR OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| These options control the C preprocessor, which is run on |
| each C source file before actual compilation. |
| |
| If you use the `----EEEE' option, GCC does nothing except prepro- |
| cessing. Some of these options make sense only together |
| with `----EEEE' because they cause the preprocessor output to be |
| unsuitable for actual compilation. |
| |
| ----iiii _f_i_l_e |
| Process _f_i_l_e as input, discarding the resulting out- |
| put, before processing the regular input file. Because |
| the output generated from _f_i_l_e is discarded, the only |
| effect of ` ----iiii _f_i_l_e' is to make the macros defined in |
| _f_i_l_e available for use in the main input. The prepro- |
| cessor evaluates any `----DDDD' and `----UUUU' options on the com- |
| mand line before processing `----iiii' _f_i_l_e. |
| |
| ----nnnnoooossssttttddddiiiinnnncccc |
| Do not search the standard system directories for |
| header files. Only the directories you have specified |
| with `----IIII' options (and the current directory, if ap- |
| propriate) are searched. |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 9 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| By using both `----nnnnoooossssttttddddiiiinnnncccc' and `----IIII---- ', you can limit the |
| include-file search file to only those directories you |
| specify explicitly. |
| |
| ----uuuunnnnddddeeeeffff |
| Do not predefine any nonstandard macros. (Including |
| architecture flags). |
| |
| ----EEEE Run only the C preprocessor. Preprocess all the C |
| source files specified and output the results to stan- |
| dard output or to the specified output file. |
| |
| ----CCCC Tell the preprocessor not to discard comments. Used |
| with the `----EEEE' option. |
| |
| ----PPPP Tell the preprocessor not to generate `####lllliiiinnnneeee' com- |
| mands. Used with the `----EEEE' option. |
| |
| ----MMMM Tell the preprocessor to output a rule suitable for |
| mmmmaaaakkkkeeee describing the dependencies of each object file. |
| For each source file, the preprocessor outputs one |
| mmmmaaaakkkkeeee-rule whose target is the object file name for that |
| source file and whose dependencies are all the files |
| `####iiiinnnncccclllluuuuddddeeee'd in it. This rule may be a single line or |
| may be continued with `\\\\'-newline if it is long. The |
| list of rules is printed on standard output instead of |
| the preprocessed C program. |
| |
| `----MMMM' implies `----EEEE'. |
| |
| ----MMMMMMMM Like `----MMMM' but the output mentions only the user header |
| files included with `####iiiinnnncccclllluuuuddddeeee _f_i_l_e"'. System header |
| files included with `####iiiinnnncccclllluuuuddddeeee <<<<_f_i_l_e>' are omitted. |
| |
| ----MMMMDDDD Like `----MMMM' but the dependency information is written to |
| files with names made by replacing `....cccc' with `....dddd' at |
| the end of the input file names. This is in addition |
| to compiling the file as specified-`----MMMMDDDD' does not inhi- |
| bit ordinary compilation the way `----MMMM' does. |
| |
| The Mach utility `mmmmdddd' can be used to merge the `....dddd' |
| files into a single dependency file suitable for using |
| with the `mmmmaaaakkkkeeee' command. |
| |
| ----MMMMMMMMDDDD Like `----MMMMDDDD' except mention only user header files, not |
| system header files. |
| |
| ----HHHH Print the name of each header file used, in addition |
| to other normal activities. |
| |
| ----DDDD_m_a_c_r_o |
| Define macro _m_a_c_r_o with the string `1111' as its defini- |
| |
| |
| |
| GNU Tools Last change: 28may1992 10 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| tion. |
| |
| ----DDDD_m_a_c_r_o====_d_e_f_n |
| Define macro _m_a_c_r_o as _d_e_f_n. All instances of `----DDDD' on |
| the command line are processed before any `----UUUU' or `----iiii' |
| options. |
| |
| ----UUUU_m_a_c_r_o |
| Undefine macro _m_a_c_r_o. `----UUUU' options are evaluated after |
| all `----DDDD' options, but before any `----iiii' options. |
| |
| ----ddddMMMM Tell the preprocessor to output only a list of the |
| macro definitions that are in effect at the end of |
| preprocessing. Used with the `----EEEE' option. |
| |
| ----ddddDDDD Tell the preprocessing to pass all macro definitions |
| into the output, in their proper sequence in the rest |
| of the output. |
| |
| ----ddddNNNN Like `----ddddDDDD' except that the macro arguments and con- |
| tents are omitted. Only `####ddddeeeeffffiiiinnnneeee _n_a_m_e' is included in |
| the output. |
| |
| LLLLIIIINNNNKKKKEEEERRRR OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| These options come into play when the compiler links object |
| files into an executable output file. They are meaningless |
| if the compiler is not doing a link step. |
| |
| _o_b_j_e_c_t-_f_i_l_e-_n_a_m_e |
| A file name that does not end in a special recognized |
| suffix is considered to name an object file or library. |
| (Object files are distinguished from libraries by the |
| linker according to the file contents.) If GCC does a |
| link step, these object files are used as input to the |
| linker. |
| |
| ----llll_l_i_b_r_a_r_y |
| Use the library named _l_i_b_r_a_r_y when linking. |
| |
| The linker searches a standard list of directories for |
| the library, which is actually a file named |
| `lllliiiibbbb_l_i_b_r_a_r_y.a'. The linker then uses this file as if |
| it had been specified precisely by name. |
| |
| The directories searched include several standard sys- |
| tem directories plus any that you specify with `----LLLL'. |
| |
| Normally the files found this way are library files - |
| archive files whose members are object files. The |
| linker handles an archive file by scanning through it |
| for members which define symbols that have so far been |
| referenced but not defined. However, if the linker |
| |
| |
| |
| GNU Tools Last change: 28may1992 11 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| finds an ordinary object file rather than a library, |
| the object file is linked in the usual fashion. The |
| only difference between using an `----llll' option and speci- |
| fying a file name is that `----llll' surrounds _l_i_b_r_a_r_y with |
| `lllliiiibbbb' and `....aaaa' and searches several directories. |
| |
| ----nnnnoooossssttttddddlllliiiibbbb |
| Don't use the standard system libraries and startup |
| files when linking. Only the files you specify will be |
| passed to the linker. |
| |
| ----ssssttttaaaattttiiiicccc |
| On systems that support dynamic linking, this prevents |
| linking with the shared libraries. On other systems, |
| this option has no effect. |
| |
| DDDDIIIIRRRREEEECCCCTTTTOOOORRRRYYYY OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| These options specify directories to search for header |
| files, for libraries and for parts of the compiler: |
| |
| ----IIII_d_i_r |
| Append directory _d_i_r to the list of directories |
| searched for include files. |
| |
| ----IIII---- Any directories you specify with `----IIII' options before |
| the ` ---- IIII ---- ' option are searched only for the case of |
| `####iiiinnnncccclllluuuuddddeeee """"_f_i_l_e""""'; they are not searched for `####iiiinnnncccclllluuuuddddeeee |
| <<<<_f_i_l_e>'. |
| |
| If additional directories are specified with `---- IIII' op- |
| tions after the `----IIII---- ', these directories are searched |
| for all `####iiiinnnncccclllluuuuddddeeee' directives. (Ordinarily _a_l_l ` ---- IIII' |
| directories are used this way.) |
| |
| In addition, the `----IIII---- ' option inhibits the use of the |
| current directory (where the current input file came |
| from) as the first search directory for `####iiiinnnncccclllluuuuddddeeee |
| """"_f_i_l_e""""'. There is no way to override this effect of `---- |
| IIII---- '. With `----IIII....' you can specify searching the direc- |
| tory which was current when the compiler was invoked. |
| That is not exactly the same as what the preprocessor |
| does by default, but it is often satisfactory. |
| |
| `----IIII---- ' does not inhibit the use of the standard system |
| directories for header files. Thus, `----IIII---- ' and `----nnnnoooosssstttt---- |
| ddddiiiinnnncccc' are independent. |
| |
| ----LLLL_d_i_r |
| Add directory _d_i_r to the list of directories to be |
| searched for `----llll'. |
| |
| ----BBBB_p_r_e_f_i_x |
| |
| |
| |
| GNU Tools Last change: 28may1992 12 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| This option specifies where to find the executables, |
| libraries and data files of the compiler itself. |
| |
| The compiler driver program runs one or more of the |
| subprograms `ccccpppppppp', `cccccccc1111' (or, for C++, `cccccccc1111pppplllluuuussss'), `aaaassss' |
| and `lllldddd'. It tries _p_r_e_f_i_x as a prefix for each program |
| it tries to run, both with and without |
| `_m_a_c_h_i_n_e/_v_e_r_s_i_o_n/'. |
| |
| For each subprogram to be run, the compiler driver |
| first tries the `----BBBB' prefix, if any. If that name is |
| not found, or if `----BBBB' was not specified, the driver |
| tries two standard prefixes, which are `////uuuussssrrrr////lllliiiibbbb////ggggcccccccc////' |
| and `////uuuussssrrrr////llllooooccccaaaallll////lllliiiibbbb////ggggcccccccc----lllliiiibbbb////'. If neither of those |
| results in a file name that is found, the compiler |
| driver searches for the unmodified program name, using |
| the directories specified in your `PPPPAAAATTTTHHHH' environment |
| variable. |
| |
| The run-time support file `lllliiiibbbbggggcccccccc....aaaa' is also searched |
| for using the ` ----BBBB' prefix, if needed. If it is not |
| found there, the two standard prefixes above are tried, |
| and that is all. The file is left out of the link if |
| it is not found by those means. Most of the time, on |
| most machines, `lllliiiibbbbggggcccccccc....aaaa' is not actually necessary. |
| |
| You can get a similar result from the environment vari- |
| able GGGGCCCCCCCC____EEEEXXXXEEEECCCC____PPPPRRRREEEEFFFFIIIIXXXX; if it is defined, its value is |
| used as a prefix in the same way. If both the `----BBBB' op- |
| tion and the GGGGCCCCCCCC____EEEEXXXXEEEECCCC____PPPPRRRREEEEFFFFIIIIXXXX variable are present, the |
| `----BBBB' option is used first and the environment variable |
| value second. |
| |
| WWWWAAAARRRRNNNNIIIINNNNGGGG OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| Warnings are diagnostic messages that report constructions |
| which are not inherently erroneous but which are risky or |
| suggest there may have been an error. |
| |
| These options control the amount and kinds of warnings pro- |
| duced by GNU CC: |
| |
| ----ffffssssyyyynnnnttttaaaaxxxx----oooonnnnllllyyyy |
| Check the code for syntax errors, but don't emit any |
| output. |
| |
| ----wwww Inhibit all warning messages. |
| |
| ----ppppeeeeddddaaaannnnttttiiiicccc |
| Issue all the warnings demanded by strict ANSI standard |
| C; reject all programs that use forbidden extensions. |
| |
| Valid ANSI standard C programs should compile properly |
| |
| |
| |
| GNU Tools Last change: 28may1992 13 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| with or without this option (though a rare few will re- |
| quire `----aaaannnnssssiiii'). However, without this option, certain |
| GNU extensions and traditional C features are supported |
| as well. With this option, they are rejected. There |
| is no reason to _u_s_e this option; it exists only to |
| satisfy pedants. |
| |
| `----ppppeeeeddddaaaannnnttttiiiicccc' does not cause warning messages for use of |
| the alternate keywords whose names begin and end with |
| `________'. Pedantic warnings are also disabled in the ex- |
| pression that follows ________eeeexxxxtttteeeennnnssssiiiioooonnnn________. However, only |
| system header files should use these escape routes; ap- |
| plication programs should avoid them. |
| |
| ----ppppeeeeddddaaaannnnttttiiiicccc----eeeerrrrrrrroooorrrrssss |
| Like `----ppppeeeeddddaaaannnnttttiiiicccc', except that errors are produced rath- |
| er than warnings. |
| |
| ----WWWW Print extra warning messages for these events: |
| |
| +o A nonvolatile automatic variable might be changed by a |
| call to lllloooonnnnggggjjjjmmmmpppp. These warnings are possible only in |
| optimizing compilation. |
| |
| The compiler sees only the calls to sssseeeettttjjjjmmmmpppp. It cannot |
| know where lllloooonnnnggggjjjjmmmmpppp will be called; in fact, a signal |
| handler could call it at any point in the code. As a |
| result, you may get a warning even when there is in |
| fact no problem because lllloooonnnnggggjjjjmmmmpppp cannot in fact be |
| called at the place which would cause a problem. |
| |
| +o A function can return either with or without a value. |
| (Falling off the end of the function body is considered |
| returning without a value.) For example, this function |
| would evoke such a warning: |
| |
| foo (a) |
| { |
| if (a > 0) |
| return a; |
| } |
| |
| |
| Spurious warnings can occur because GNU CC does not |
| realize that certain functions (including aaaabbbboooorrrrtttt and |
| lllloooonnnnggggjjjjmmmmpppp) will never return. |
| |
| +o An expression-statement contains no side effects. |
| |
| +o An unsigned value is compared against zero with `>>>>' or |
| `<<<<===='. |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 14 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----WWWWiiiimmmmpppplllliiiicccciiiitttt |
| Warn whenever a function or parameter is implicitly de- |
| clared. |
| |
| ----WWWWrrrreeeettttuuuurrrrnnnn----ttttyyyyppppeeee |
| Warn whenever a function is defined with a return-type |
| that defaults to iiiinnnntttt. Also warn about any rrrreeeettttuuuurrrrnnnn |
| statement with no return-value in a function whose |
| return-type is not vvvvooooiiiidddd. |
| |
| ----WWWWuuuunnnnuuuusssseeeedddd |
| Warn whenever a local variable is unused aside from its |
| declaration, whenever a function is declared static but |
| never defined, and whenever a statement computes a |
| result that is explicitly not used. |
| |
| ----WWWWsssswwwwiiiittttcccchhhh |
| Warn whenever a sssswwwwiiiittttcccchhhh statement has an index of |
| enumeral type and lacks a ccccaaaasssseeee for one or more of the |
| named codes of that enumeration. (The presence of a |
| ddddeeeeffffaaaauuuulllltttt label prevents this warning.) ccccaaaasssseeee labels out- |
| side the enumeration range also provoke warnings when |
| this option is used. |
| |
| ----WWWWccccoooommmmmmmmeeeennnntttt |
| Warn whenever a comment-start sequence `////****' appears in |
| a comment. |
| |
| ----WWWWttttrrrriiiiggggrrrraaaapppphhhhssss |
| Warn if any trigraphs are encountered (assuming they |
| are enabled). |
| |
| ----WWWWffffoooorrrrmmmmaaaatttt |
| Check calls to pppprrrriiiinnnnttttffff and ssssccccaaaannnnffff, etc., to make sure |
| that the arguments supplied have types appropriate to |
| the format string specified. |
| |
| ----WWWWuuuunnnniiiinnnniiiittttiiiiaaaalllliiiizzzzeeeedddd |
| An automatic variable is used without first being ini- |
| tialized. |
| |
| These warnings are possible only in optimizing compila- |
| tion, because they require data flow information that |
| is computed only when optimizing. If you don't specify |
| `----OOOO', you simply won't get these warnings. |
| |
| These warnings occur only for variables that are candi- |
| dates for register allocation. Therefore, they do not |
| occur for a variable that is declared vvvvoooollllaaaattttiiiilllleeee, or |
| whose address is taken, or whose size is other than 1, |
| 2, 4 or 8 bytes. Also, they do not occur for struc- |
| tures, unions or arrays, even when they are in regis- |
| |
| |
| |
| GNU Tools Last change: 28may1992 15 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ters. |
| |
| Note that there may be no warning about a variable that |
| is used only to compute a value that itself is never |
| used, because such computations may be deleted by data |
| flow analysis before the warnings are printed. |
| |
| These warnings are made optional because GNU CC is not |
| smart enough to see all the reasons why the code might |
| be correct despite appearing to have an error. Here is |
| one example of how this can happen: |
| |
| |
| { |
| int x; |
| switch (y) |
| { |
| case 1: x = 1; |
| break; |
| case 2: x = 4; |
| break; |
| case 3: x = 5; |
| } |
| foo (x); |
| } |
| |
| |
| |
| If the value of yyyy is always 1, 2 or 3, then xxxx is always |
| initialized, but GNU CC doesn't know this. Here is |
| another common case: |
| |
| |
| { |
| int save_y; |
| if (change_y) save_y = y, y = new_y; |
| ... |
| if (change_y) y = save_y; |
| } |
| |
| |
| |
| This has no bug because ssssaaaavvvveeee____yyyy is used only if it is |
| set. |
| |
| Some spurious warnings can be avoided if you declare as |
| vvvvoooollllaaaattttiiiilllleeee all the functions you use that never return. |
| |
| ----WWWWppppaaaarrrreeeennnntttthhhheeeesssseeeessss |
| Warn if parentheses are omitted in certain contexts. |
| |
| ----WWWWaaaallllllll |
| |
| |
| |
| GNU Tools Last change: 28may1992 16 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| All of the above `----WWWW' options combined. These are all |
| the options which pertain to usage that we recommend |
| avoiding and that we believe is easy to avoid, even in |
| conjunction with macros. |
| |
| The remaining `----WWWW............' options are not implied by `----WWWWaaaallllllll' be- |
| cause they warn about constructions that we consider reason- |
| able to use, on occasion, in clean programs. |
| |
| ----WWWWttttrrrraaaaddddiiiittttiiiioooonnnnaaaallll |
| Warn about certain constructs that behave differently |
| in traditional and ANSI C. |
| |
| +o Macro arguments occurring within string constants in |
| the macro body. These would substitute the argument in |
| traditional C, but are part of the constant in ANSI C. |
| |
| +o A function declared external in one block and then |
| used after the end of the block. |
| |
| +o A sssswwwwiiiittttcccchhhh statement has an operand of type lllloooonnnngggg. |
| |
| ----WWWWsssshhhhaaaaddddoooowwww |
| Warn whenever a local variable shadows another local |
| variable. |
| |
| ----WWWWiiiidddd----ccccllllaaaasssshhhh----_l_e_n |
| Warn whenever two distinct identifiers match in the |
| first _l_e_n characters. This may help you prepare a pro- |
| gram that will compile with certain obsolete, brain- |
| damaged compilers. |
| |
| ----WWWWppppooooiiiinnnntttteeeerrrr----aaaarrrriiiitttthhhh |
| Warn about anything that depends on the ``size of'' a |
| function type or of vvvvooooiiiidddd. GNU C assigns these types a |
| size of 1, for convenience in calculations with vvvvooooiiiidddd **** |
| pointers and pointers to functions. |
| |
| ----WWWWccccaaaasssstttt----qqqquuuuaaaallll |
| Warn whenever a pointer is cast so as to remove a type |
| qualifier from the target type. For example, warn if a |
| ccccoooonnnnsssstttt cccchhhhaaaarrrr **** is cast to an ordinary cccchhhhaaaarrrr ****. |
| |
| ----WWWWccccaaaasssstttt----aaaalllliiiiggggnnnn |
| Warn whenever a pointer is cast such that the required |
| alignment of the target is increased. For example, |
| warn if a cccchhhhaaaarrrr **** is cast to an iiiinnnntttt **** on machines where |
| integers can only be accessed at two- or four-byte |
| boundaries. |
| |
| ----WWWWwwwwrrrriiiitttteeee----ssssttttrrrriiiinnnnggggssss |
| Give string constants the type ccccoooonnnnsssstttt cccchhhhaaaarrrr[[[[_l_e_n_g_t_h] so |
| |
| |
| |
| GNU Tools Last change: 28may1992 17 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| that copying the address of one into a non-ccccoooonnnnsssstttt cccchhhhaaaarrrr **** |
| pointer will get a warning. These warnings will help |
| you find at compile time code that can try to write |
| into a string constant, but only if you have been very |
| careful about using ccccoooonnnnsssstttt in declarations and proto- |
| types. Otherwise, it will just be a nuisance; this is |
| why we did not make `----WWWWaaaallllllll' request these warnings. |
| |
| ----WWWWccccoooonnnnvvvveeeerrrrssssiiiioooonnnn |
| Warn if a prototype causes a type conversion that is |
| different from what would happen to the same argument |
| in the absence of a prototype. This includes conver- |
| sions of fixed point to floating and vice versa, and |
| conversions changing the width or signedness of a fixed |
| point argument except when the same as the default pro- |
| motion. |
| |
| ----WWWWaaaaggggggggrrrreeeeggggaaaatttteeee----rrrreeeettttuuuurrrrnnnn |
| Warn if any functions that return structures or unions |
| are defined or called. (In languages where you can re- |
| turn an array, this also elicits a warning.) |
| |
| ----WWWWssssttttrrrriiiicccctttt----pppprrrroooottttoooottttyyyyppppeeeessss |
| Warn if a function is declared or defined without |
| specifying the argument types. (An old-style function |
| definition is permitted without a warning if preceded |
| by a declaration which specifies the argument types.) |
| |
| ----WWWWmmmmiiiissssssssiiiinnnngggg----pppprrrroooottttoooottttyyyyppppeeeessss |
| Warn if a global function is defined without a previous |
| prototype declaration. This warning is issued even if |
| the definition itself provides a prototype. The aim is |
| to detect global functions that fail to be declared in |
| header files. |
| |
| ----WWWWeeeennnnuuuummmm----ccccllllaaaasssshhhh |
| (_C++ _o_n_l_y.) Warn when converting between different |
| enumeration types. |
| |
| ----WWWWoooovvvveeeerrrrllllooooaaaaddddeeeedddd----vvvviiiirrrrttttuuuuaaaallll |
| (_C++ _o_n_l_y.) In a derived class, the definitions of vir- |
| tual functions must match the type signature of a vir- |
| tual function declared in the base class. Use this op- |
| tion to request warnings when a derived class declares |
| a function that may be an erroneous attempt to define a |
| virtual function: that is, warn when a function with |
| the same name as a virtual function in the base class, |
| but with a type signature that doesn't match any virtu- |
| al functions from the base class. |
| |
| ----WWWWiiiinnnnlllliiiinnnneeee |
| Warn if a function can not be inlined, and either it |
| |
| |
| |
| GNU Tools Last change: 28may1992 18 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| was declared as inline, or else the ----ffffiiiinnnnlllliiiinnnneeee----ffffuuuunnnnccccttttiiiioooonnnnssss |
| option was given. |
| |
| ----WWWWeeeerrrrrrrroooorrrr |
| Treat warnings as errors; abort compilation after any |
| warning. |
| |
| DDDDEEEEBBBBUUUUGGGGGGGGIIIINNNNGGGG OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| GNU CC has various special options that are used for debug- |
| ging either your program or GCC: |
| |
| ---- gggg Produce debugging information in the operating |
| system's native format (for DBX or SDB or DWARF). GDB |
| also can work with this debugging information. On most |
| systems that use DBX format, `----gggg' enables use of extra |
| debugging information that only GDB can use; if you |
| want to control for certain whether to generate this |
| information, use `----ggggggggddddbbbb' or `----ggggddddbbbbxxxx'. |
| |
| Unlike most other C compilers, GNU CC allows you to use |
| ` ----gggg' with `----OOOO'. The shortcuts taken by optimized code |
| may occasionally produce surprising results: some vari- |
| ables you declared may not exist at all; flow of con- |
| trol may briefly move where you did not expect it; some |
| statements may not be executed because they compute |
| constant results or their values were already at hand; |
| some statements may execute in different places because |
| they were moved out of loops. |
| |
| Nevertheless it proves possible to debug optimized out- |
| put. This makes it reasonable to use the optimizer for |
| programs that might have bugs. |
| |
| The following options are useful when GNU CC is config- |
| ured and compiled with the capability for more than one |
| debugging format. |
| |
| ----ggggggggddddbbbb |
| Produce debugging information in DBX format (if that is |
| supported), including GDB extensions. |
| |
| ----ggggddddbbbbxxxx |
| Produce debugging information in DBX format (if that is |
| supported), without GDB extensions. |
| |
| ----ggggssssddddbbbb |
| Produce debugging information in SDB format (if that is |
| supported). |
| |
| ----ggggddddwwwwaaaarrrrffff |
| Produce debugging information in DWARF format (if that |
| is supported). |
| |
| |
| |
| GNU Tools Last change: 28may1992 19 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----gggg_l_e_v_e_l |
| ----ggggggggddddbbbb_l_e_v_e_l |
| ----ggggddddbbbbxxxx_l_e_v_e_l |
| ----ggggssssddddbbbb_l_e_v_e_l |
| |
| ----ggggddddwwwwaaaarrrrffff_l_e_v_e_l |
| Request debugging information and also use _l_e_v_e_l to |
| specify how much information. The default level is 2. |
| |
| Level 1 produces minimal information, enough for making |
| backtraces in parts of the program that you don't plan |
| to debug. This includes descriptions of functions and |
| external variables, but no information about local |
| variables and no line numbers. |
| |
| ----pppp Generate extra code to write profile information suit- |
| able for the analysis program pppprrrrooooffff. |
| |
| ----ppppgggg Generate extra code to write profile information suit- |
| able for the analysis program ggggpppprrrrooooffff. |
| |
| ----aaaa Generate extra code to write profile information for |
| basic blocks, which will record the number of times |
| each basic block is executed. This data could be |
| analyzed by a program like ttttccccoooovvvv. Note, however, that |
| the format of the data is not what ttttccccoooovvvv expects. Even- |
| tually GNU ggggpppprrrrooooffff should be extended to process this |
| data. |
| |
| ----dddd_l_e_t_t_e_r_s |
| Says to make debugging dumps during compilation at |
| times specified by _l_e_t_t_e_r_s. This is used for debugging |
| the compiler. The file names for most of the dumps are |
| made by appending a word to the source file name (e.g. |
| `ffffoooooooo....cccc....rrrrttttllll' or `ffffoooooooo....cccc....jjjjuuuummmmpppp'). |
| |
| ----ddddMMMM Dump all macro definitions, at the end of preprocess- |
| ing, and write no output. |
| |
| ----ddddNNNN Dump all macro names, at the end of preprocessing. |
| |
| ----ddddDDDD Dump all macro definitions, at the end of preprocess- |
| ing, in addition to normal output. |
| |
| ----ddddyyyy Dump debugging information during parsing, to standard |
| error. |
| |
| ----ddddrrrr Dump after RTL generation, to `_f_i_l_e.rtl'. |
| |
| ----ddddxxxx Just generate RTL for a function instead of compiling |
| it. Usually used with `rrrr'. |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 20 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----ddddjjjj Dump after first jump optimization, to `_f_i_l_e.jump'. |
| |
| ----ddddssss Dump after CSE (including the jump optimization that |
| sometimes follows CSE), to `_f_i_l_e.cse'. |
| |
| ----ddddLLLL Dump after loop optimization, to `_f_i_l_e.loop'. |
| |
| ----ddddtttt Dump after the second CSE pass (including the jump op- |
| timization that sometimes follows CSE), to `_f_i_l_e.cse2'. |
| |
| ----ddddffff Dump after flow analysis, to `_f_i_l_e.flow'. |
| |
| ----ddddcccc Dump after instruction combination, to `_f_i_l_e.combine'. |
| |
| ----ddddSSSS Dump after the first instruction scheduling pass, to |
| `_f_i_l_e.sched'. |
| |
| ----ddddllll Dump after local register allocation, to `_f_i_l_e.lreg'. |
| |
| ----ddddgggg Dump after global register allocation, to `_f_i_l_e.greg'. |
| |
| ----ddddRRRR Dump after the second instruction scheduling pass, to |
| `_f_i_l_e.sched2'. |
| |
| ----ddddJJJJ Dump after last jump optimization, to `_f_i_l_e.jump2'. |
| |
| ----dddddddd Dump after delayed branch scheduling, to `_f_i_l_e.dbr'. |
| |
| ----ddddkkkk Dump after conversion from registers to stack, to |
| `_f_i_l_e.stack'. |
| |
| ----ddddmmmm Print statistics on memory usage, at the end of the |
| run, to standard error. |
| |
| ----ddddpppp Annotate the assembler output with a comment indicat- |
| ing which pattern and alternative was used. |
| |
| ----ffffpppprrrreeeetttteeeennnndddd----ffffllllooooaaaatttt |
| When running a cross-compiler, pretend that the target |
| machine uses the same floating point format as the host |
| machine. This causes incorrect output of the actual |
| floating constants, but the actual instruction sequence |
| will probably be the same as GNU CC would make when |
| running on the target machine. |
| |
| ----ssssaaaavvvveeee----tttteeeemmmmppppssss |
| Store the usual ``temporary'' intermediate files per- |
| manently; place them in the current directory and name |
| them based on the source file. Thus, compiling `ffffoooooooo....cccc' |
| with `----cccc ----ssssaaaavvvveeee----tttteeeemmmmppppssss' would produce files `ffffoooooooo....ccccpppppppp' and |
| `ffffoooooooo....ssss', as well as `ffffoooooooo....oooo'. |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 21 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| OOOOPPPPTTTTIIIIMMMMIIIIZZZZAAAATTTTIIIIOOOONNNN OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| These options control various sorts of optimizations: |
| |
| ----OOOO Optimize. Optimizing compilation takes somewhat more |
| time, and a lot more memory for a large function. |
| |
| Without `----OOOO', the compiler's goal is to reduce the cost |
| of compilation and to make debugging produce the ex- |
| pected results. Statements are independent: if you |
| stop the program with a breakpoint between statements, |
| you can then assign a new value to any variable or |
| change the program counter to any other statement in |
| the function and get exactly the results you would ex- |
| pect from the source code. |
| |
| Without `----OOOO', only variables declared rrrreeeeggggiiiisssstttteeeerrrr are al- |
| located in registers. The resulting compiled code is a |
| little worse than produced by PCC without `----OOOO'. |
| |
| With `----OOOO', the compiler tries to reduce code size and |
| execution time. |
| |
| When you specify `----OOOO', `----fffftttthhhhrrrreeeeaaaadddd----jjjjuuuummmmppppssss' and `----ffffddddeeeellllaaaayyyyeeeedddd---- |
| bbbbrrrraaaannnncccchhhh' are turned on. On some machines other flags |
| may also be turned on. |
| |
| ----OOOO2222 Highly optimize. As compared to ` ---- OOOO', this option |
| will increase both compilation time and the performance |
| of the generated code. |
| |
| All `----ffff_f_l_a_g' options that control optimization are |
| turned on when you specify `----OOOO2222', except `----ffffuuuunnnnrrrroooollllllll---- |
| llllooooooooppppssss' and `----ffffuuuunnnnrrrroooollllllll----aaaallllllll----llllooooooooppppssss'. |
| |
| Options of the form ` ---- ffff_f_l_a_g' specify machine-independent |
| flags. Most flags have both positive and negative forms; |
| the negative form of `----ffffffffoooooooo' would be `----ffffnnnnoooo----ffffoooooooo'. The fol- |
| lowing list shows only one form-the one which is not the de- |
| fault. You can figure out the other form by either removing |
| `nnnnoooo---- ' or adding it. |
| |
| ----ffffffffllllooooaaaatttt----ssssttttoooorrrreeee |
| Do not store floating point variables in registers. |
| This prevents undesirable excess precision on machines |
| such as the 68000 where the floating registers (of the |
| 68881) keep more precision than a ddddoooouuuubbbblllleeee is supposed to |
| have. |
| |
| For most programs, the excess precision does only good, |
| but a few programs rely on the precise definition of |
| IEEE floating point. Use `----ffffffffllllooooaaaatttt----ssssttttoooorrrreeee' for such pro- |
| grams. |
| |
| |
| |
| GNU Tools Last change: 28may1992 22 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----ffffmmmmeeeemmmmooooiiiizzzzeeee----llllooooooookkkkuuuuppppssss |
| |
| ----ffffssssaaaavvvveeee----mmmmeeeemmmmooooiiiizzzzeeeedddd |
| (_C++ _o_n_l_y.) These flags are used to get the compiler |
| to compile programs faster using heuristics. They are |
| not on by default since they are only effective about |
| half the time. The other half of the time programs |
| compile more slowly (and take more memory). |
| |
| The first time the compiler must build a call to a |
| member function (or reference to a data member), it |
| must (1) determine whether the class implements member |
| functions of that name; (2) resolve which member func- |
| tion to call (which involves figuring out what sorts of |
| type conversions need to be made); and (3) check the |
| visibility of the member function to the caller. All |
| of this adds up to slower compilation. Normally, the |
| second time a call is made to that member function (or |
| reference to that data member), it must go through the |
| same lengthy process again. This means that code like |
| this |
| |
| cout << "This " << p << " has " << n << " legs.\n"; |
| |
| makes six passes through all three steps. By using a |
| software cache, a ``hit'' significantly reduces this |
| cost. Unfortunately, using the cache introduces anoth- |
| er layer of mechanisms which must be implemented, and |
| so incurs its own overhead. `----ffffmmmmeeeemmmmooooiiiizzzzeeee ---- llllooooooookkkkuuuuppppssss' en- |
| ables the software cache. |
| |
| Because access privileges (visibility) to members and |
| member functions may differ from one function context |
| to the next, gggg++++++++ may need to flush the cache. With the |
| ` ---- ffffmmmmeeeemmmmooooiiiizzzzeeee ----llllooooooookkkkuuuuppppssss' flag, the cache is flushed after |
| every function that is compiled. The `-fsave-memoized' |
| flag enables the same software cache, but when the com- |
| piler determines that the context of the last function |
| compiled would yield the same access privileges of the |
| next function to compile, it preserves the cache. This |
| is most helpful when defining many member functions for |
| the same class: with the exception of member functions |
| which are friends of other classes, each member func- |
| tion has exactly the same access privileges as every |
| other, and the cache need not be flushed. |
| |
| ----ffffnnnnoooo----ddddeeeeffffaaaauuuulllltttt----iiiinnnnlllliiiinnnneeee |
| (_C++ _o_n_l_y.) If `----ffffddddeeeeffffaaaauuuulllltttt ---- iiiinnnnlllliiiinnnneeee' is enabled then |
| member functions defined inside class scope are com- |
| piled inline by default; i.e., you don't need to add |
| `iiiinnnnlllliiiinnnneeee' in front of the member function name. By po- |
| pular demand, this option is now the default. To keep |
| |
| |
| |
| GNU Tools Last change: 28may1992 23 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| GNU C++ from inlining these member functions, specify ` |
| ----ffffnnnnoooo----ddddeeeeffffaaaauuuulllltttt----iiiinnnnlllliiiinnnneeee'. |
| |
| ----ffffnnnnoooo----ddddeeeeffffeeeerrrr----ppppoooopppp |
| Always pop the arguments to each function call as soon |
| as that function returns. For machines which must pop |
| arguments after a function call, the compiler normally |
| lets arguments accumulate on the stack for several |
| function calls and pops them all at once. |
| |
| ----ffffffffoooorrrrcccceeee----mmmmeeeemmmm |
| Force memory operands to be copied into registers be- |
| fore doing arithmetic on them. This may produce better |
| code by making all memory references potential common |
| subexpressions. When they are not common subexpres- |
| sions, instruction combination should eliminate the |
| separate register-load. I am interested in hearing |
| about the difference this makes. |
| |
| ----ffffffffoooorrrrcccceeee----aaaaddddddddrrrr |
| Force memory address constants to be copied into regis- |
| ters before doing arithmetic on them. This may produce |
| better code just as `----ffffffffoooorrrrcccceeee----mmmmeeeemmmm' may. I am interested |
| in hearing about the difference this makes. |
| |
| ----ffffoooommmmiiiitttt----ffffrrrraaaammmmeeee----ppppooooiiiinnnntttteeeerrrr |
| Don't keep the frame pointer in a register for func- |
| tions that don't need one. This avoids the instruc- |
| tions to save, set up and restore frame pointers; it |
| also makes an extra register available in many func- |
| tions. _I_t _a_l_s_o _m_a_k_e_s _d_e_b_u_g_g_i_n_g _i_m_p_o_s_s_i_b_l_e _o_n most |
| machines. |
| |
| On some machines, such as the Vax, this flag has no ef- |
| fect, because the standard calling sequence automati- |
| cally handles the frame pointer and nothing is saved by |
| pretending it doesn't exist. The machine-description |
| macro FFFFRRRRAAAAMMMMEEEE____PPPPOOOOIIIINNNNTTTTEEEERRRR____RRRREEEEQQQQUUUUIIIIRRRREEEEDDDD controls whether a target |
| machine supports this flag. |
| |
| ----ffffiiiinnnnlllliiiinnnneeee |
| Pay attention the iiiinnnnlllliiiinnnneeee keyword. Normally the nega- |
| tion of this option `----ffffnnnnoooo----iiiinnnnlllliiiinnnneeee' is used to keep the |
| compiler from expanding any functions inline. However, |
| the opposite effect may be desirable when compiling |
| with `----gggg', since `----gggg' normally turns off all inline |
| function expansion. |
| |
| ----ffffiiiinnnnlllliiiinnnneeee----ffffuuuunnnnccccttttiiiioooonnnnssss |
| Integrate all simple functions into their callers. The |
| compiler heuristically decides which functions are sim- |
| ple enough to be worth integrating in this way. |
| |
| |
| |
| GNU Tools Last change: 28may1992 24 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| If all calls to a given function are integrated, and |
| the function is declared ssssttttaaaattttiiiicccc, then GCC normally does |
| not output the function as assembler code in its own |
| right. |
| |
| ----ffffccccaaaalllllllleeeerrrr----ssssaaaavvvveeeessss |
| Enable values to be allocated in registers that will be |
| clobbered by function calls, by emitting extra instruc- |
| tions to save and restore the registers around such |
| calls. Such allocation is done only when it seems to |
| result in better code than would otherwise be produced. |
| |
| This option is enabled by default on certain machines, |
| usually those which have no call-preserved registers to |
| use instead. |
| |
| ----ffffkkkkeeeeeeeepppp----iiiinnnnlllliiiinnnneeee----ffffuuuunnnnccccttttiiiioooonnnnssss |
| Even if all calls to a given function are integrated, |
| and the function is declared ssssttttaaaattttiiiicccc, nevertheless out- |
| put a separate run-time callable version of the func- |
| tion. |
| |
| ----ffffnnnnoooo----ffffuuuunnnnccccttttiiiioooonnnn----ccccsssseeee |
| Do not put function addresses in registers; make each |
| instruction that calls a constant function contain the |
| function's address explicitly. |
| |
| This option results in less efficient code, but some |
| strange hacks that alter the assembler output may be |
| confused by the optimizations performed when this op- |
| tion is not used. |
| |
| The following options control specific optimizations. The ` |
| ---- OOOO2222' option turns on all of these optimizations except `---- |
| ffffuuuunnnnrrrroooollllllll----llllooooooooppppssss' and `----ffffuuuunnnnrrrroooollllllll----aaaallllllll----llllooooooooppppssss'. |
| |
| The `----OOOO' option usually turns on the `----fffftttthhhhrrrreeeeaaaadddd----jjjjuuuummmmppppssss' and `---- |
| ffffddddeeeellllaaaayyyyeeeedddd ---- bbbbrrrraaaannnncccchhhh' options, but specific machines may change |
| the default optimizations. |
| |
| You can use the following flags in the rare cases when |
| ``fine-tuning'' of optimizations to be performed is desired. |
| |
| ----ffffssssttttrrrreeeennnnggggtttthhhh----rrrreeeedddduuuucccceeee |
| Perform the optimizations of loop strength reduction |
| and elimination of iteration variables. |
| |
| ----fffftttthhhhrrrreeeeaaaadddd----jjjjuuuummmmppppssss |
| Perform optimizations where we check to see if a jump |
| branches to a location where another comparison sub- |
| sumed by the first is found. If so, the first branch |
| is redirected to either the destination of the second |
| |
| |
| |
| GNU Tools Last change: 28may1992 25 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| branch or a point immediately following it, depending |
| on whether the condition is known to be true or false. |
| |
| ----ffffuuuunnnnrrrroooollllllll----llllooooooooppppssss |
| Perform the optimization of loop unrolling. This is |
| only done for loops whose number of iterations can be |
| determined at compile time or run time. |
| |
| ----ffffuuuunnnnrrrroooollllllll----aaaallllllll----llllooooooooppppssss |
| Perform the optimization of loop unrolling. This is |
| done for all loops. This usually makes programs run |
| more slowly. |
| |
| ----ffffccccsssseeee----ffffoooolllllllloooowwww----jjjjuuuummmmppppssss |
| In common subexpression elimination, scan through jump |
| instructions in certain cases. This is not as powerful |
| as completely global CSE, but not as slow either. |
| |
| ----ffffrrrreeeerrrruuuunnnn----ccccsssseeee----aaaafffftttteeeerrrr----lllloooooooopppp |
| Re-run common subexpression elimination after loop op- |
| timizations has been performed. |
| |
| ----ffffeeeelllliiiiddddeeee----ccccoooonnnnssssttttrrrruuuuccccttttoooorrrrssss |
| (_C++ _o_n_l_y.) Use this option to instruct the compiler |
| to be smarter about when it can elide constructors. |
| Without this flag, GNU C++ and cfront both generate ef- |
| fectively the same code for: |
| |
| A foo (); |
| A x (foo ()); // x initialized by `foo ()', no ctor called |
| A y = foo (); // call to `foo ()' heads to temporary, |
| // y is initialized from the temporary. |
| |
| Note the difference! With this flag, GNU C++ initial- |
| izes `yyyy' directly from the call to ffffoooooooo (((()))) without going |
| through a temporary. |
| |
| ----ffffeeeexxxxppppeeeennnnssssiiiivvvveeee----ooooppppttttiiiimmmmiiiizzzzaaaattttiiiioooonnnnssss |
| Perform a number of minor optimizations that are rela- |
| tively expensive. |
| |
| ----ffffddddeeeellllaaaayyyyeeeedddd----bbbbrrrraaaannnncccchhhh |
| If supported for the target machine, attempt to reorder |
| instructions to exploit instruction slots available |
| after delayed branch instructions. |
| |
| ----ffffsssscccchhhheeeedddduuuulllleeee----iiiinnnnssssnnnnssss |
| If supported for the target machine, attempt to reorder |
| instructions to eliminate execution stalls due to re- |
| quired data being unavailable. This helps machines |
| that have slow floating point or memory load instruc- |
| tions by allowing other instructions to be issued until |
| |
| |
| |
| GNU Tools Last change: 28may1992 26 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| the result of the load or floating point instruction is |
| required. |
| |
| ----ffffsssscccchhhheeeedddduuuulllleeee----iiiinnnnssssnnnnssss2222 |
| Similar to `----ffffsssscccchhhheeeedddduuuulllleeee----iiiinnnnssssnnnnssss', but requests an addi- |
| tional pass of instruction scheduling after register |
| allocation has been done. This is especially useful on |
| machines with a relatively small number of registers |
| and where memory load instructions take more than one |
| cycle. |
| |
| TTTTAAAARRRRGGGGEEEETTTT OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| By default, GNU CC compiles code for the same type of |
| machine that you are using. However, it can also be in- |
| stalled as a cross-compiler, to compile for some other type |
| of machine. In fact, several different configurations of |
| GNU CC, for different target machines, can be installed side |
| by side. Then you specify which one to use with the `----bbbb' |
| option. |
| |
| In addition, older and newer versions of GNU CC can be in- |
| stalled side by side. One of them (probably the newest) |
| will be the default, but you may sometimes wish to use |
| another. |
| |
| ----bbbb _m_a_c_h_i_n_e |
| The argument _m_a_c_h_i_n_e specifies the target machine for |
| compilation. This is useful when you have installed |
| GNU CC as a cross-compiler. |
| |
| The value to use for _m_a_c_h_i_n_e is the same as was speci- |
| fied as the machine type when configuring GNU CC as a |
| cross-compiler. For example, if a cross-compiler was |
| configured with `ccccoooonnnnffffiiiigggguuuurrrreeee i386v', meaning to compile |
| for an 80386 running System V, then you would specify ` |
| ----bbbb iiii333388886666vvvv' to run that cross compiler. |
| |
| When you do not specify `----bbbb', it normally means to com- |
| pile for the same type of machine that you are using. |
| |
| ----VVVV _v_e_r_s_i_o_n |
| The argument _v_e_r_s_i_o_n specifies which version of GNU CC |
| to run. This is useful when multiple versions are in- |
| stalled. For example, _v_e_r_s_i_o_n might be `2222....0000', meaning |
| to run GNU CC version 2.0. |
| |
| The default version, when you do not specify `---- VVVV', is |
| controlled by the way GNU CC is installed. Normally, |
| it will be a version that is recommended for general |
| use. |
| |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 27 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| MMMMAAAACCCCHHHHIIIINNNNEEEE DDDDEEEEPPPPEEEENNNNDDDDEEEENNNNTTTT OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| Each of the target machine types can have its own special |
| options, starting with ` ---- mmmm', to choose among various |
| hardware models or configurations - for example, 68010 vs |
| 68020, floating coprocessor or none. A single installed |
| version of the compiler can compile for any model or confi- |
| guration, according to the options specified. |
| |
| These are the `----mmmm' options defined for the 68000 series: |
| |
| ----mmmm66668888000022220000 |
| |
| ----mmmmcccc66668888000022220000 |
| Generate output for a 68020 (rather than a 68000). |
| This is the default if you use the unmodified sources. |
| |
| ----mmmm66668888000000000000 |
| |
| ----mmmmcccc66668888000000000000 |
| Generate output for a 68000 (rather than a 68020). |
| |
| ----mmmm66668888888888881111 |
| Generate output containing 68881 instructions for |
| floating point. This is the default if you use the un- |
| modified sources. |
| |
| ----mmmmffffppppaaaa |
| Generate output containing Sun FPA instructions for |
| floating point. |
| |
| ----mmmmssssoooofffftttt----ffffllllooooaaaatttt |
| Generate output containing library calls for floating |
| point. _W_A_R_N_I_N_G: the requisite libraries are not part |
| of GNU CC. Normally the facilities of the machine's |
| usual C compiler are used, but this can't be done |
| directly in cross-compilation. You must make your own |
| arrangements to provide suitable library functions for |
| cross-compilation. |
| |
| ----mmmmsssshhhhoooorrrrtttt |
| Consider type iiiinnnntttt to be 16 bits wide, like sssshhhhoooorrrrtttt iiiinnnntttt. |
| |
| ----mmmmnnnnoooobbbbiiiittttffffiiiieeeelllldddd |
| Do not use the bit-field instructions. `---- mmmm66668888000000000000' im- |
| plies `----mmmmnnnnoooobbbbiiiittttffffiiiieeeelllldddd'. |
| |
| ----mmmmbbbbiiiittttffffiiiieeeelllldddd |
| Do use the bit-field instructions. `----mmmm66668888000022220000' implies ` |
| ---- mmmmbbbbiiiittttffffiiiieeeelllldddd'. This is the default if you use the unmo- |
| dified sources. |
| |
| ----mmmmrrrrttttdddd |
| |
| |
| |
| GNU Tools Last change: 28may1992 28 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| Use a different function-calling convention, in which |
| functions that take a fixed number of arguments return |
| with the rrrrttttdddd instruction, which pops their arguments |
| while returning. This saves one instruction in the |
| caller since there is no need to pop the arguments |
| there. |
| |
| This calling convention is incompatible with the one |
| normally used on Unix, so you cannot use it if you need |
| to call libraries compiled with the Unix compiler. |
| |
| Also, you must provide function prototypes for all |
| functions that take variable numbers of arguments (in- |
| cluding pppprrrriiiinnnnttttffff); otherwise incorrect code will be gen- |
| erated for calls to those functions. |
| |
| In addition, seriously incorrect code will result if |
| you call a function with too many arguments. (Normal- |
| ly, extra arguments are harmlessly ignored.) |
| |
| The rrrrttttdddd instruction is supported by the 68010 and 68020 |
| processors, but not by the 68000. |
| |
| These `----mmmm' options are defined for the Vax: |
| |
| ----mmmmuuuunnnniiiixxxx |
| Do not output certain jump instructions (aaaaoooobbbblllleeeeqqqq and so |
| on) that the Unix assembler for the Vax cannot handle |
| across long ranges. |
| |
| ----mmmmggggnnnnuuuu |
| Do output those jump instructions, on the assumption |
| that you will assemble with the GNU assembler. |
| |
| ----mmmmgggg Output code for g-format floating point numbers in- |
| stead of d-format. |
| |
| These `----mmmm' switches are supported on the Sparc: |
| |
| ----mmmmffffppppuuuu |
| Generate output containing floating point instructions. |
| This is the default if you use the unmodified sources. |
| |
| ----mmmmnnnnoooo----eeeeppppiiiilllloooogggguuuueeee |
| Generate separate return instructions for rrrreeeettttuuuurrrrnnnn state- |
| ments. This has both advantages and disadvantages; I |
| don't recall what they are. |
| |
| These `----mmmm' options are defined for the Convex: |
| |
| ----mmmmcccc1111 Generate output for a C1. This is the default when |
| the compiler is configured for a C1. |
| |
| |
| |
| GNU Tools Last change: 28may1992 29 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----mmmmcccc2222 Generate output for a C2. This is the default when |
| the compiler is configured for a C2. |
| |
| ----mmmmaaaarrrrggggccccoooouuuunnnntttt |
| Generate code which puts an argument count in the word |
| preceding each argument list. Some nonportable Convex |
| and Vax programs need this word. (Debuggers don't, ex- |
| cept for functions with variable-length argument lists; |
| this info is in the symbol table.) |
| |
| ----mmmmnnnnooooaaaarrrrggggccccoooouuuunnnntttt |
| Omit the argument count word. This is the default if |
| you use the unmodified sources. |
| |
| These `----mmmm' options are defined for the AMD Am29000: |
| |
| ----mmmmddddwwww Generate code that assumes the DW bit is set, i.e., |
| that byte and halfword operations are directly support- |
| ed by the hardware. This is the default. |
| |
| ----mmmmnnnnooooddddwwww |
| Generate code that assumes the DW bit is not set. |
| |
| ----mmmmbbbbwwww Generate code that assumes the system supports byte |
| and halfword write operations. This is the default. |
| |
| ----mmmmnnnnbbbbwwww |
| Generate code that assumes the systems does not support |
| byte and halfword write operations. This implies `---- |
| mmmmnnnnooooddddwwww'. |
| |
| ----mmmmssssmmmmaaaallllllll |
| Use a small memory model that assumes that all function |
| addresses are either within a single 256 KB segment or |
| at an absolute address of less than 256K. This allows |
| the ccccaaaallllllll instruction to be used instead of a ccccoooonnnnsssstttt, |
| ccccoooonnnnsssstttthhhh, ccccaaaalllllllliiii sequence. |
| |
| ----mmmmllllaaaarrrrggggeeee |
| Do not assume that the ccccaaaallllllll instruction can be used; |
| this is the default. |
| |
| ----mmmm22229999000055550000 |
| Generate code for the Am29050. |
| |
| ----mmmm22229999000000000000 |
| Generate code for the Am29000. This is the default. |
| |
| ----mmmmkkkkeeeerrrrnnnneeeellll----rrrreeeeggggiiiisssstttteeeerrrrssss |
| Generate references to registers ggggrrrr66664444----ggggrrrr99995555 instead of |
| ggggrrrr99996666----ggggrrrr111122227777. This option can be used when compiling |
| kernel code that wants a set of global registers dis- |
| |
| |
| |
| GNU Tools Last change: 28may1992 30 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| joint from that used by user-mode code. |
| |
| Note that when this option is used, register names in ` |
| ----ffff' flags must use the normal, user-mode, names. |
| |
| ----mmmmuuuusssseeeerrrr----rrrreeeeggggiiiisssstttteeeerrrrssss |
| Use the normal set of global registers, ggggrrrr99996666----ggggrrrr111122227777. |
| This is the default. |
| |
| ----mmmmssssttttaaaacccckkkk----cccchhhheeeecccckkkk |
| Insert a call to ________mmmmsssspppp____cccchhhheeeecccckkkk after each stack adjust- |
| ment. This is often used for kernel code. |
| |
| These `----mmmm' options are defined for Motorola 88K architec- |
| tures: |
| |
| ----mmmmbbbbiiiigggg----ppppiiiicccc |
| Emit position-independent code, suitable for dynamic |
| linking, even if branches need large displacements. |
| Equivalent to the general-use option ` ---- ffffPPPPIIIICCCC'. The |
| general-use option ` ---- ffffppppiiiicccc', by contrast, only emits |
| valid 88k code if all branches involve small displace- |
| ments. GCC does not emit position-independent code by |
| default. |
| |
| ----mmmmiiiiddddeeeennnnttttiiiiffffyyyy----rrrreeeevvvviiiissssiiiioooonnnn |
| Include an iiiiddddeeeennnntttt directive in the assembler output |
| recording the source file name, compiler name and ver- |
| sion, timestamp, and compilation flags used. |
| |
| ----mmmmnnnnoooo----uuuunnnnddddeeeerrrrssssccccoooorrrreeeessss |
| In assembler output, emit symbol names without adding |
| an underscore character at the beginning of each name. |
| The default is to use an underscore as prefix on each |
| name. |
| |
| ----mmmmnnnnoooo----cccchhhheeeecccckkkk----zzzzeeeerrrroooo----ddddiiiivvvviiiissssiiiioooonnnn |
| |
| ----mmmmcccchhhheeeecccckkkk----zzzzeeeerrrroooo----ddddiiiivvvviiiissssiiiioooonnnn |
| Early models of the 88K architecture had problems with |
| division by zero; in particular, many of them didn't |
| trap. Use these options to avoid including (or to in- |
| clude explicitly) additional code to detect division by |
| zero and signal an exception. All GCC configurations |
| for the 88K use `----mmmmcccchhhheeeecccckkkk----zzzzeeeerrrroooo----ddddiiiivvvviiiissssiiiioooonnnn' by default. |
| |
| ----mmmmooooccccssss----ddddeeeebbbbuuuugggg----iiiinnnnffffoooo |
| |
| ----mmmmnnnnoooo----ooooccccssss----ddddeeeebbbbuuuugggg----iiiinnnnffffoooo |
| Include (or omit) additional debugging information |
| (about registers used in each stack frame) as specified |
| in the 88Open Object Compatibility Standard, ``OCS''. |
| |
| |
| |
| GNU Tools Last change: 28may1992 31 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| This extra information is not needed by GDB. The de- |
| fault for DG/UX, SVr4, and Delta 88 SVr3.2 is to in- |
| clude this information; other 88k configurations omit |
| this information by default. |
| |
| ----mmmmooooccccssss----ffffrrrraaaammmmeeee----ppppoooossssiiiittttiiiioooonnnn |
| |
| ----mmmmnnnnoooo----ooooccccssss----ffffrrrraaaammmmeeee----ppppoooossssiiiittttiiiioooonnnn |
| Force (or do not require) register values to be stored |
| in a particular place in stack frames, as specified in |
| OCS. The DG/UX, Delta88 SVr3.2, and BCS configurations |
| use ` ---- mmmmooooccccssss----ffffrrrraaaammmmeeee----ppppoooossssiiiittttiiiioooonnnn'; other 88k configurations |
| have the default `----mmmmnnnnoooo----ooooccccssss----ffffrrrraaaammmmeeee----ppppoooossssiiiittttiiiioooonnnn'. |
| |
| ----mmmmooooppppttttiiiimmmmiiiizzzzeeee----aaaarrrrgggg----aaaarrrreeeeaaaa |
| |
| ----mmmmnnnnoooo----ooooppppttttiiiimmmmiiiizzzzeeee----aaaarrrrgggg----aaaarrrreeeeaaaa |
| Control how to store function arguments in stack |
| frames. ` ---- mmmmooooppppttttiiiimmmmiiiizzzzeeee ----aaaarrrrgggg----aaaarrrreeeeaaaa' saves space, but may |
| break some debuggers (not GDB). `----mmmmnnnnoooo----ooooppppttttiiiimmmmiiiizzzzeeee ---- aaaarrrrgggg ---- |
| aaaarrrreeeeaaaa' conforms better to standards. By default GCC |
| does not optimize the argument area. |
| |
| ----mmmmsssshhhhoooorrrrtttt----ddddaaaattttaaaa----_n_u_m |
| _n_u_m Generate smaller data references by making them |
| relative to rrrr0000, which allows loading a value using a |
| single instruction (rather than the usual two). You |
| control which data references are affected by specify- |
| ing _n_u_m with this option. For example, if you specify |
| ` ---- mmmmsssshhhhoooorrrrtttt----ddddaaaattttaaaa----555511112222', then the data references affected |
| are those involving displacements of less than 512 |
| bytes. ` ---- mmmmsssshhhhoooorrrrtttt----ddddaaaattttaaaa---- _n_u_m' is not effective for _n_u_m |
| greater than 64K. |
| |
| ----mmmmssssvvvvrrrr4444 |
| |
| ----mmmmssssvvvvrrrr3333 |
| Turn on (`----mmmmssssvvvvrrrr4444') or off (`---- mmmmssssvvvvrrrr3333') compiler exten- |
| sions related to System V release 4 (SVr4). This con- |
| trols the following: |
| |
| +o Which variant of the assembler syntax to emit (which |
| you can select independently using `----mmmmvvvveeeerrrrssssiiiioooonnnn00003333....00000000'). |
| |
| +o `----mmmmssssvvvvrrrr4444' makes the C preprocessor recognize `####pppprrrraaaaggggmmmmaaaa |
| wwwweeeeaaaakkkk' |
| |
| +o `----mmmmssssvvvvrrrr4444' makes GCC issue additional declaration direc- |
| tives used in SVr4. |
| |
| `----mmmmssssvvvvrrrr3333' is the default for all m88K configurations except |
| the SVr4 configuration. |
| |
| |
| |
| GNU Tools Last change: 28may1992 32 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----mmmmttttrrrraaaapppp----llllaaaarrrrggggeeee----sssshhhhiiiifffftttt |
| |
| ----mmmmhhhhaaaannnnddddlllleeee----llllaaaarrrrggggeeee----sssshhhhiiiifffftttt |
| Include code to detect bit-shifts of more than 31 bits; |
| respectively, trap such shifts or emit code to handle |
| them properly. By default GCC makes no special provi- |
| sion for large bit shifts. |
| |
| ----mmmmuuuusssseeee----ddddiiiivvvv----iiiinnnnssssttttrrrruuuuccccttttiiiioooonnnn |
| Very early models of the 88K architecture didn't have a |
| divide instruction, so GCC avoids that instruction by |
| default. Use this option to specify that it's safe to |
| use the divide instruction. |
| |
| ----mmmmvvvveeeerrrrssssiiiioooonnnn----00003333....00000000 |
| Use alternative assembler syntax for the assembler ver- |
| sion corresponding to SVr4, but without enabling the |
| other features triggered by `----ssssvvvvrrrr4444'. This is implied |
| by ` ----ssssvvvvrrrr4444', is the default for the SVr4 configuration |
| of GCC, and is permitted by the DG/UX configuration |
| only if `----ssssvvvvrrrr4444' is also specified. The Delta 88 SVr3.2 |
| configuration ignores this option. |
| |
| ----mmmmwwwwaaaarrrrnnnn----ppppaaaasssssssseeeedddd----ssssttttrrrruuuuccccttttssss |
| Warn when a function passes a struct as an argument or |
| result. Structure-passing conventions have changed |
| during the evolution of the C language, and are often |
| the source of portability problems. By default, GCC |
| issues no such warning. |
| |
| These options are defined for the IBM RS6000: |
| |
| |
| ----mmmmffffpppp----iiiinnnn----ttttoooocccc |
| |
| ----mmmmnnnnoooo----ffffpppp----iiiinnnn----ttttoooocccc |
| Control whether or not floating-point constants go in |
| the Table of Contents (TOC), a table of all global |
| variable and function addresses. By default GCC puts |
| floating-point constants there; if the TOC overflows, ` |
| ----mmmmnnnnoooo----ffffpppp----iiiinnnn----ttttoooocccc' will reduce the size of the TOC, which |
| may avoid the overflow. |
| |
| |
| These `----mmmm' options are defined for the IBM RT PC: |
| |
| ----mmmmiiiinnnn----lllliiiinnnneeee----mmmmuuuullll |
| Use an in-line code sequence for integer multiplies. |
| This is the default. |
| |
| ----mmmmccccaaaallllllll----lllliiiibbbb----mmmmuuuullll |
| Call llllmmmmuuuullll$$$$$$$$ for integer multiples. |
| |
| |
| |
| GNU Tools Last change: 28may1992 33 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----mmmmffffuuuullllllll----ffffpppp----bbbblllloooocccckkkkssss |
| Generate full-size floating point data blocks, includ- |
| ing the minimum amount of scratch space recommended by |
| IBM. This is the default. |
| |
| ----mmmmmmmmiiiinnnniiiimmmmuuuummmm----ffffpppp----bbbblllloooocccckkkkssss |
| Do not include extra scratch space in floating point |
| data blocks. This results in smaller code, but slower |
| execution, since scratch space must be allocated dynam- |
| ically. |
| |
| ----mmmmffffpppp----aaaarrrrgggg----iiiinnnn----ffffpppprrrreeeeggggssss |
| Use a calling sequence incompatible with the IBM cal- |
| ling convention in which floating point arguments are |
| passed in floating point registers. Note that |
| vvvvaaaarrrraaaarrrrggggssss....hhhh and ssssttttddddaaaarrrrggggssss....hhhh will not work with floating |
| point operands if this option is specified. |
| |
| ----mmmmffffpppp----aaaarrrrgggg----iiiinnnn----ggggrrrreeeeggggssss |
| Use the normal calling convention for floating point |
| arguments. This is the default. |
| |
| ----mmmmhhhhcccc----ssssttttrrrruuuucccctttt----rrrreeeettttuuuurrrrnnnn |
| Return structures of more than one word in memory, |
| rather than in a register. This provides compatibility |
| with the MetaWare HighC (hc) compiler. Use ` ---- ffffppppcccccccc ---- |
| ssssttttrrrruuuucccctttt ---- rrrreeeettttuuuurrrrnnnn' for compatibility with the Portable C |
| Compiler (pcc). |
| |
| ----mmmmnnnnoooohhhhcccc----ssssttttrrrruuuucccctttt----rrrreeeettttuuuurrrrnnnn |
| Return some structures of more than one word in regis- |
| ters, when convenient. This is the default. For com- |
| patibility with the IBM-supplied compilers, use either |
| `----ffffppppcccccccc----ssssttttrrrruuuucccctttt----rrrreeeettttuuuurrrrnnnn' or `----mmmmhhhhcccc----ssssttttrrrruuuucccctttt----rrrreeeettttuuuurrrrnnnn'. |
| |
| These `----mmmm' options are defined for the MIPS family of com- |
| puters: |
| |
| ----mmmmccccppppuuuu====_c_p_u-_t_y_p_e |
| Assume the defaults for the machine type _c_p_u-_t_y_p_e when |
| scheduling instructions. The default _c_p_u-_t_y_p_e is ddddeeee---- |
| ffffaaaauuuulllltttt, which picks the longest cycles times for any of |
| the machines, in order that the code run at reasonable |
| rates on all MIPS cpu's. Other choices for _c_p_u-_t_y_p_e |
| are rrrr2222000000000000, rrrr3333000000000000, rrrr4444000000000000, and rrrr6666000000000000. While picking a |
| specific _c_p_u-_t_y_p_e will schedule things appropriately |
| for that particular chip, the compiler will not gen- |
| erate any code that does not meet level 1 of the MIPS |
| ISA (instruction set architecture) without the ----mmmmiiiippppssss2222 |
| or ----mmmmiiiippppssss3333 switches being used. |
| |
| ----mmmmiiiippppssss2222 |
| |
| |
| |
| GNU Tools Last change: 28may1992 34 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| Issue instructions from level 2 of the MIPS ISA (branch |
| likely, square root instructions). The ----mmmmccccppppuuuu====rrrr4444000000000000 or |
| ----mmmmccccppppuuuu====rrrr6666000000000000 switch must be used in conjunction with ---- |
| mmmmiiiippppssss2222. |
| |
| ----mmmmiiiippppssss3333 |
| Issue instructions from level 3 of the MIPS ISA (64 bit |
| instructions). The ----mmmmccccppppuuuu====rrrr4444000000000000 switch must be used in |
| conjunction with ----mmmmiiiippppssss2222. |
| |
| ----mmmmiiiinnnntttt66664444 |
| |
| ----mmmmlllloooonnnngggg66664444 |
| |
| ----mmmmlllloooonnnngggglllloooonnnngggg111122228888 |
| These options don't work at present. |
| |
| ----mmmmmmmmiiiippppssss----aaaassss |
| Generate code for the MIPS assembler, and invoke mmmmiiiippppssss ---- |
| ttttffffiiiilllleeee to add normal debug information. This is the de- |
| fault for all platforms except for the OSF/1 reference |
| platform, using the OSF/rose object format. If any of |
| the ----ggggggggddddbbbb, ----ggggssssttttaaaabbbbssss, or ----ggggssssttttaaaabbbbssss++++ switches are used, the |
| mmmmiiiippppssss ---- ttttffffiiiilllleeee program will encapsulate the stabs within |
| MIPS ECOFF. |
| |
| ----mmmmggggaaaassss |
| Generate code for the GNU assembler. This is the de- |
| fault on the OSF/1 reference platform, using the |
| OSF/rose object format. |
| |
| ----mmmmrrrrnnnnaaaammmmeeeessss |
| |
| ----mmmmnnnnoooo----rrrrnnnnaaaammmmeeeessss |
| The ----mmmmrrrrnnnnaaaammmmeeeessss switch says to output code using the MIPS |
| software names for the registers, instead of the |
| hardware names (ie, aaaa0000 instead of $$$$4444). The GNU assem- |
| bler does not support the ----mmmmrrrrnnnnaaaammmmeeeessss switch, and the MIPS |
| assembler will be instructed to run the MIPS C prepro- |
| cessor over the source file. The ----mmmmnnnnoooo----rrrrnnnnaaaammmmeeeessss switch is |
| default. |
| |
| ----mmmmggggppppoooopppptttt |
| |
| ----mmmmnnnnoooo----ggggppppoooopppptttt |
| The ----mmmmggggppppoooopppptttt switch says to write all of the data de- |
| clarations before the instructions in the text section, |
| to all the MIPS assembler to generate one word memory |
| references instead of using two words for short global |
| or static data items. This is on by default if optimi- |
| zation is selected. |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 35 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----mmmmssssttttaaaattttssss |
| |
| ----mmmmnnnnoooo----ssssttttaaaattttssss |
| For each non-inline function processed, the ---- mmmmssssttttaaaattttssss |
| switch causes the compiler to emit one line to the |
| standard error file to print statistics about the pro- |
| gram (number of registers saved, stack size, etc.). |
| |
| ----mmmmmmmmeeeemmmmccccppppyyyy |
| |
| ----mmmmnnnnoooo----mmmmeeeemmmmccccppppyyyy |
| The ----mmmmmmmmeeeemmmmccccppppyyyy switch makes all block moves call the ap- |
| propriate string function (mmmmeeeemmmmccccppppyyyy or bbbbccccooooppppyyyy) instead of |
| possibly generating inline code. |
| |
| ----mmmmmmmmiiiippppssss----ttttffffiiiilllleeee |
| |
| ----mmmmnnnnoooo----mmmmiiiippppssss----ttttffffiiiilllleeee |
| The ----mmmmnnnnoooo----mmmmiiiippppssss----ttttffffiiiilllleeee switch causes the compiler not |
| postprocess the object file with the mmmmiiiippppssss----ttttffffiiiilllleeee pro- |
| gram, after the MIPS assembler has generated it to add |
| debug support. If mmmmiiiippppssss----ttttffffiiiilllleeee is not run, then no local |
| variables will be available to the debugger. In addi- |
| tion, ssssttttaaaaggggeeee2222 and ssssttttaaaaggggeeee3333 objects will have the temporary |
| file names passed to the assembler embedded in the ob- |
| ject file, which means the objects will not compare the |
| same. |
| |
| ----mmmmssssoooofffftttt----ffffllllooooaaaatttt |
| Generate output containing library calls for floating |
| point. _W_A_R_N_I_N_G: the requisite libraries are not part |
| of GNU CC. Normally the facilities of the machine's |
| usual C compiler are used, but this can't be done |
| directly in cross-compilation. You must make your own |
| arrangements to provide suitable library functions for |
| cross-compilation. |
| |
| ----mmmmhhhhaaaarrrrdddd----ffffllllooooaaaatttt |
| Generate output containing floating point instructions. |
| This is the default if you use the unmodified sources. |
| |
| ----mmmmffffpppp66664444 |
| Assume that the FFFFRRRR bit in the status word is on, and |
| that there are 32 64-bit floating point registers, in- |
| stead of 32 32-bit floating point registers. You must |
| also specify the ----mmmmccccppppuuuu====rrrr4444000000000000 and ----mmmmiiiippppssss3333 switches. |
| |
| ----mmmmffffpppp33332222 |
| Assume that there are 32 32-bit floating point regis- |
| ters. This is the default. |
| |
| ----mmmmaaaabbbbiiiiccccaaaallllllllssss |
| |
| |
| |
| GNU Tools Last change: 28may1992 36 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| The ----mmmmaaaabbbbiiiiccccaaaallllllllssss switch says to emit the ....aaaabbbbiiiiccccaaaallllllllssss, |
| ....ccccppppllllooooaaaadddd, and ....ccccpppprrrreeeessssttttoooorrrreeee pseudo operations that some |
| System V.4 ports use for position independent code. |
| |
| ----mmmmhhhhaaaallllffff----ppppiiiicccc |
| |
| ----mmmmnnnnoooo----hhhhaaaallllffff----ppppiiiicccc |
| The ----mmmmhhhhaaaallllffff----ppppiiiicccc switch says to put pointers to extern |
| references into the data section and load them up, |
| rather than put the references in the text section. |
| This option does not work at present. ----GGGG_n_u_m Put global |
| and static items less than or equal to _n_u_m bytes into |
| the small data or bss sections instead of the normal |
| data or bss section. This allows the assembler to emit |
| one word memory reference instructions based on the |
| global pointer (ggggpppp or $$$$22228888), instead of the normal two |
| words used. By default, _n_u_m is 8 when the MIPS assem- |
| bler is used, and 0 when the GNU assembler is used. |
| The ---- GGGG_n_u_m switch is also passed to the assembler and |
| linker. All modules should be compiled with the same ---- |
| GGGG_n_u_m value. |
| |
| CCCCOOOODDDDEEEE GGGGEEEENNNNEEEERRRRAAAATTTTIIIIOOOONNNN OOOOPPPPTTTTIIIIOOOONNNNSSSS |
| These machine-independent options control the interface con- |
| ventions used in code generation. |
| |
| Most of them begin with `-f'. These options have both posi- |
| tive and negative forms; the negative form of `----ffffffffoooooooo' would |
| be `----ffffnnnnoooo----ffffoooooooo'. In the table below, only one of the forms is |
| listed-the one which is not the default. You can figure out |
| the other form by either removing `nnnnoooo---- ' or adding it. |
| |
| ++++eeee_N (_C++ _o_n_l_y.) control whether virtual function defini- |
| tions in classes are used to generate code, or only to |
| define interfaces for their callers. These options are |
| provided for compatibility with cfront 1.x usage; the |
| recommended GNU C++ usage is to use ####pppprrrraaaaggggmmmmaaaa iiiinnnntttteeeerrrrffffaaaacccceeee |
| and ####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn, instead. |
| |
| With `++++eeee0000', virtual function definitions in classes are |
| declared extern; the declaration is used only as an in- |
| terface specification, not to generate code for the |
| virtual functions (in this compilation). |
| |
| With `++++eeee1111', gggg++++++++ actually generates the code implement- |
| ing virtual functions defined in the code, and makes |
| them publicly visible. |
| |
| ----ffffnnnnoooonnnnnnnnuuuullllllll----oooobbbbjjjjeeeeccccttttssss |
| (_C++ _o_n_l_y.) Normally, GNU C++ makes conservative as- |
| sumptions about objects reached through references. |
| For example, the compiler must check that `aaaa' is not |
| |
| |
| |
| GNU Tools Last change: 28may1992 37 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| null in code like the following: |
| obj &a = g (); |
| a.f (2); |
| Checking that references of this sort have non-null |
| values requires extra code, however, and it is unneces- |
| sary for many programs. You can use ` ---- ffffnnnnoooonnnnnnnnuuuullllllll ---- oooobbbb---- |
| jjjjeeeeccccttttssss' to omit the checks for null, if your program |
| doesn't require the default checking. |
| |
| ----ffffppppcccccccc----ssssttttrrrruuuucccctttt----rrrreeeettttuuuurrrrnnnn |
| Use the same convention for returning ssssttttrrrruuuucccctttt and uuuunnnniiiioooonnnn |
| values that is used by the usual C compiler on your |
| system. This convention is less efficient for small |
| structures, and on many machines it fails to be reen- |
| trant; but it has the advantage of allowing intercalla- |
| bility between GCC-compiled code and PCC-compiled code. |
| |
| ----ffffsssshhhhoooorrrrtttt----eeeennnnuuuummmmssss |
| Allocate to an eeeennnnuuuummmm type only as many bytes as it needs |
| for the declared range of possible values. Specifical- |
| ly, the eeeennnnuuuummmm type will be equivalent to the smallest |
| integer type which has enough room. |
| |
| ----ffffsssshhhhoooorrrrtttt----ddddoooouuuubbbblllleeee |
| Use the same size for ddddoooouuuubbbblllleeee as for ffffllllooooaaaatttt . |
| |
| ----ffffsssshhhhaaaarrrreeeedddd----ddddaaaattttaaaa |
| Requests that the data and non-ccccoooonnnnsssstttt variables of this |
| compilation be shared data rather than private data. |
| The distinction makes sense only on certain operating |
| systems, where shared data is shared between processes |
| running the same program, while private data exists in |
| one copy per process. |
| |
| ----ffffnnnnoooo----ccccoooommmmmmmmoooonnnn |
| Allocate even uninitialized global variables in the bss |
| section of the object file, rather than generating them |
| as common blocks. This has the effect that if the same |
| variable is declared (without eeeexxxxtttteeeerrrrnnnn) in two different |
| compilations, you will get an error when you link them. |
| The only reason this might be useful is if you wish to |
| verify that the program will work on other systems |
| which always work this way. |
| |
| ----ffffvvvvoooollllaaaattttiiiilllleeee |
| Consider all memory references through pointers to be |
| volatile. |
| |
| ----ffffppppiiiicccc |
| If supported for the target machines, generate |
| position-independent code, suitable for use in a shared |
| library. |
| |
| |
| |
| GNU Tools Last change: 28may1992 38 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----ffffPPPPIIIICCCC |
| If supported for the target machine, emit position- |
| independent code, suitable for dynamic linking, even if |
| branches need large displacements. |
| |
| ----ffffffffiiiixxxxeeeedddd----_r_e_g |
| Treat the register named _r_e_g as a fixed register; gen- |
| erated code should never refer to it (except perhaps as |
| a stack pointer, frame pointer or in some other fixed |
| role). |
| |
| _r_e_g must be the name of a register. The register names |
| accepted are machine-specific and are defined in the |
| RRRREEEEGGGGIIIISSSSTTTTEEEERRRR____NNNNAAAAMMMMEEEESSSS macro in the machine description macro |
| file. |
| |
| This flag does not have a negative form, because it |
| specifies a three-way choice. |
| |
| ----ffffccccaaaallllllll----uuuusssseeeedddd----_r_e_g |
| Treat the register named _r_e_g as an allocatable regis- |
| ter that is clobbered by function calls. It may be al- |
| located for temporaries or variables that do not live |
| across a call. Functions compiled this way will not |
| save and restore the register _r_e_g. |
| |
| Use of this flag for a register that has a fixed per- |
| vasive role in the machine's execution model, such as |
| the stack pointer or frame pointer, will produce disas- |
| trous results. |
| |
| This flag does not have a negative form, because it |
| specifies a three-way choice. |
| |
| ----ffffccccaaaallllllll----ssssaaaavvvveeeedddd----_r_e_g |
| Treat the register named _r_e_g as an allocatable regis- |
| ter saved by functions. It may be allocated even for |
| temporaries or variables that live across a call. |
| Functions compiled this way will save and restore the |
| register _r_e_g if they use it. |
| |
| Use of this flag for a register that has a fixed per- |
| vasive role in the machine's execution model, such as |
| the stack pointer or frame pointer, will produce disas- |
| trous results. |
| |
| A different sort of disaster will result from the use |
| of this flag for a register in which function values |
| may be returned. |
| |
| This flag does not have a negative form, because it |
| specifies a three-way choice. |
| |
| |
| |
| GNU Tools Last change: 28may1992 39 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| ----ffffggggnnnnuuuu----bbbbiiiinnnnuuuuttttiiiillllssss |
| |
| ----ffffnnnnoooo----ggggnnnnuuuu----bbbbiiiinnnnuuuuttttiiiillllssss |
| (_C++ _o_n_l_y.) `----ffffggggnnnnuuuu----bbbbiiiinnnnuuuuttttiiiillllssss ' (the default for most, |
| but not all, platforms) makes GNU C++ emit extra infor- |
| mation for static initialization and finalization. |
| This information has to be passed from the assembler to |
| the GNU linker. Some assemblers won't pass this infor- |
| mation; you must either use GNU aaaassss or specify the op- |
| tion `----ffffnnnnoooo----ggggnnnnuuuu----bbbbiiiinnnnuuuuttttiiiillllssss'. |
| |
| With `----ffffnnnnoooo----ggggnnnnuuuu----bbbbiiiinnnnuuuuttttiiiillllssss', you must use the program ccccoooollll---- |
| lllleeeecccctttt (part of the GCC distribution) for linking. |
| |
| PPPPRRRRAAAAGGGGMMMMAAAASSSS |
| Two `####pppprrrraaaaggggmmmmaaaa' directives are supported for GNU C++, to per- |
| mit using the same header file for two purposes: as a defin- |
| ition of interfaces to a given object class, and as the full |
| definition of the contents of that object class. |
| |
| ####pppprrrraaaaggggmmmmaaaa iiiinnnntttteeeerrrrffffaaaacccceeee |
| (_C++ _o_n_l_y.) Use this directive in header files that de- |
| fine object classes, to save space in most of the ob- |
| ject files that use those classes. Normally, local |
| copies of certain information (backup copies of inline |
| member functions, debugging information, and the inter- |
| nal tables that implement virtual functions) must be |
| kept in each object file that includes class defini- |
| tions. You can use this pragma to avoid such duplica- |
| tion. When a header file containing `####pppprrrraaaaggggmmmmaaaa iiiinnnntttteeeerrrr---- |
| ffffaaaacccceeee' is included in a compilation, this auxiliary in- |
| formation will not be generated (unless the main input |
| source file itself uses `####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn'). In- |
| stead, the object files will contain references to be |
| resolved at link time. |
| |
| ####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn |
| |
| ####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn """"_o_b_j_e_c_t_s....hhhh"""" |
| (_C++ _o_n_l_y.) Use this pragma in a main input file, when |
| you want full output from included header files to be |
| generated (and made globally visible). The included |
| header file, in turn, should use `####pppprrrraaaaggggmmmmaaaa iiiinnnntttteeeerrrrffffaaaacccceeee'. |
| Backup copies of inline member functions, debugging in- |
| formation, and the internal tables used to implement |
| virtual functions are all generated in implementation |
| files. |
| |
| If you use `####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn' with no argument, |
| it applies to an include file with the same basename as |
| your source file; for example, in `aaaallllllllccccllllaaaassssssss....cccccccc', |
| `####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn' by itself is equivalent to |
| |
| |
| |
| GNU Tools Last change: 28may1992 40 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| `####pppprrrraaaaggggmmmmaaaa iiiimmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn """"aaaallllllllccccllllaaaassssssss....hhhh""""'. Use the string |
| argument if you want a single implementation file to |
| include code from multiple header files. |
| |
| There is no way to split up the contents of a single |
| header file into multiple implementation files. |
| |
| FFFFIIIILLLLEEEESSSS |
| file.c C source file |
| file.h C header (preprocessor) file |
| file.i preprocessed C source file |
| file.C C++ source file |
| file.cc C++ source file |
| file.cxx C++ source file |
| file.m Objective-C source file |
| file.s assembly language file |
| file.o object file |
| a.out link edited output |
| _T_M_P_D_I_R/cc* temporary files |
| _L_I_B_D_I_R/cpp preprocessor |
| _L_I_B_D_I_R/cc1 compiler for C |
| _L_I_B_D_I_R/cc1plus compiler for C++ |
| _L_I_B_D_I_R/collect linker front end needed on some machines |
| _L_I_B_D_I_R/libgcc.a GCC subroutine library |
| /lib/crt[01n].o start-up routine |
| _L_I_B_D_I_R/ccrt0 additional start-up routine for C++ |
| /lib/libc.a standard C library, see _i_n_t_r_o(3) |
| /usr/include standard directory for ####iiiinnnncccclllluuuuddddeeee files |
| _L_I_B_D_I_R/include standard gcc directory for ####iiiinnnncccclllluuuuddddeeee files |
| _L_I_B_D_I_R/g++-include additional g++ directory for ####iiiinnnncccclllluuuuddddeeee |
| |
| _L_I_B_D_I_R is usually ////uuuussssrrrr////llllooooccccaaaallll////lllliiiibbbb////_m_a_c_h_i_n_e/_v_e_r_s_i_o_n. |
| _T_M_P_D_I_R comes from the environment variable TTTTMMMMPPPPDDDDIIIIRRRR (default |
| ////uuuussssrrrr////ttttmmmmpppp if available, else ////ttttmmmmpppp). |
| |
| SSSSEEEEEEEE AAAALLLLSSSSOOOO |
| cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1). |
| `ggggcccccccc', `ccccpppppppp', `aaaassss',````ld'''',,,, and `ggggddddbbbb' entries in iiiinnnnffffoooo. |
| _U_s_i_n_g _a_n_d _P_o_r_t_i_n_g _G_N_U _C_C (_f_o_r _v_e_r_s_i_o_n _2._0), Richard M. |
| Stallman, November 1990; _T_h_e _C _P_r_e_p_r_o_c_e_s_s_o_r, Richard M. |
| Stallman, July 1990; _U_s_i_n_g _G_D_B: _A _G_u_i_d_e _t_o _t_h_e _G_N_U _S_o_u_r_c_e- |
| _L_e_v_e_l _D_e_b_u_g_g_e_r, Richard M. Stallman and Roland H. Pesch, De- |
| cember 1991; _U_s_i_n_g _a_s: _t_h_e _G_N_U _A_s_s_e_m_b_l_e_r, Dean Elsner, Jay |
| Fenlason & friends, March 1991; _g_l_d: _t_h_e _G_N_U _l_i_n_k_e_r, Steve |
| Chamberlain and Roland Pesch, April 1991. |
| |
| |
| BBBBUUUUGGGGSSSS |
| Report bugs to bbbbuuuugggg----ggggcccccccc@@@@pppprrrreeeepppp....aaaaiiii....mmmmiiiitttt....eeeedddduuuu. Bugs tend actually |
| to be fixed if they can be isolated, so it is in your in- |
| terest to report them in such a way that they can be easily |
| reproduced. |
| |
| |
| |
| GNU Tools Last change: 28may1992 41 |
| |
| |
| |
| |
| |
| |
| GCC(1) GNU Tools GCC(1) |
| |
| |
| |
| CCCCOOOOPPPPYYYYIIIINNNNGGGG |
| Copyright (c) 1991 Free Software Foundation, Inc. |
| |
| Permission is granted to make and distribute verbatim copies |
| of this manual provided the copyright notice and this per- |
| mission notice are preserved on all copies. |
| |
| Permission is granted to copy and distribute modified ver- |
| sions of this manual under the conditions for verbatim copy- |
| ing, provided that the entire resulting derived work is dis- |
| tributed under the terms of a permission notice identical to |
| this one. |
| |
| Permission is granted to copy and distribute translations of |
| this manual into another language, under the above condi- |
| tions for modified versions, except that this permission no- |
| tice may be included in translations approved by the Free |
| Software Foundation instead of in the original English. |
| |
| AAAAUUUUTTTTHHHHOOOORRRRSSSS |
| See the GNU CC Manual for the contributors to GNU CC. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| GNU Tools Last change: 28may1992 42 |
| |
| |
| |