![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-2 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-2 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: Invoking G++, Next: C Dialect Options, Prev: Overall Options, Up: Invoking GCC
32:
33: Compiling C++ Programs
34: ======================
35:
36: C++ source files conventionally use one of the suffixes `.C', `.cc',
37: or `.cxx'; preprocessed C++ files use the suffix `.ii'. GNU CC
38: recognizes files with these names and compiles them as C++ programs
39: even if you call the compiler the same way as for compiling C programs
40: (usually with the name `gcc').
41:
42: However, C++ programs often require class libraries as well as a
43: compiler that understands the C++ language--and under some
44: circumstances, you might want to compile programs from standard input,
45: or otherwise without a suffix that flags them as C++ programs. `g++'
46: is a shell script that calls GNU CC with the default language set to
47: C++, and automatically specifies linking against the GNU class library
48: libg++. (1) On many systems, the script `g++' is also installed with
49: the name `c++'.
50:
51: When you compile C++ programs, you may specify many of the same
52: command-line options that you use for compiling programs in any
53: language; or command-line options meaningful for C and related
54: languages; or options that are meaningful only for C++ programs. *Note
55: Options Controlling C Dialect: C Dialect Options, for explanations of
56: options for languages related to C. *Note Options Controlling C++
57: Dialect: C++ Dialect Options, for explanations of options that are
58: meaningful only for C++ programs.
59:
60: ---------- Footnotes ----------
61:
62: (1) Prior to release 2 of the compiler, there was a separate `g++'
63: compiler. That version was based on GNU CC, but not integrated with
64: it. Versions of `g++' with a `1.XX' version number--for example, `g++'
65: version 1.37 or 1.42--are much less reliable than the versions
66: integrated with GCC 2. Moreover, combining G++ `1.XX' with a version 2
67: GCC will simply not work.
68:
69:
70: File: gcc.info, Node: C Dialect Options, Next: C++ Dialect Options, Prev: Invoking G++, Up: Invoking GCC
71:
72: Options Controlling C Dialect
73: =============================
74:
75: The following options control the dialect of C (or languages derived
76: from C, such as C++ and Objective C) that the compiler accepts:
77:
78: `-ansi'
79: Support all ANSI standard C programs.
80:
81: This turns off certain features of GNU C that are incompatible
82: with ANSI C, such as the `asm', `inline' and `typeof' keywords, and
83: predefined macros such as `unix' and `vax' that identify the type
84: of system you are using. It also enables the undesirable and
85: rarely used ANSI trigraph feature, and disallows `$' as part of
86: identifiers.
87:
88: The alternate keywords `__asm__', `__extension__', `__inline__'
89: and `__typeof__' continue to work despite `-ansi'. You would not
90: want to use them in an ANSI C program, of course, but it useful to
91: put them in header files that might be included in compilations
92: done with `-ansi'. Alternate predefined macros such as `__unix__'
93: and `__vax__' are also available, with or without `-ansi'.
94:
95: The `-ansi' option does not cause non-ANSI programs to be rejected
96: gratuitously. For that, `-pedantic' is required in addition to
97: `-ansi'. *Note Warning Options::.
98:
99: The macro `__STRICT_ANSI__' is predefined when the `-ansi' option
100: is used. Some header files may notice this macro and refrain from
101: declaring certain functions or defining certain macros that the
102: ANSI standard doesn't call for; this is to avoid interfering with
103: any programs that might use these names for other things.
104:
105: The functions `alloca', `abort', `exit', and `_exit' are not
106: builtin functions when `-ansi' is used.
107:
108: `-fno-asm'
109: Do not recognize `asm', `inline' or `typeof' as a keyword. These
110: words may then be used as identifiers. You can use the keywords
111: `__asm__', `__inline__' and `__typeof__' instead. `-ansi' implies
112: `-fno-asm'.
113:
114: `-fno-builtin'
115: Don't recognize builtin functions that do not begin with two
116: leading underscores. Currently, the functions affected include
117: `abort', `abs', `alloca', `cos', `exit', `fabs', `ffs', `labs',
118: `memcmp', `memcpy', `sin', `sqrt', `strcmp', `strcpy', and
119: `strlen'.
120:
121: GCC normally generates special code to handle certain builtin
122: functions more efficiently; for instance, calls to `alloca' may
123: become single instructions that adjust the stack directly, and
124: calls to `memcpy' may become inline copy loops. The resulting
125: code is often both smaller and faster, but since the function
126: calls no longer appear as such, you cannot set a breakpoint on
127: those calls, nor can you change the behavior of the functions by
128: linking with a different library.
129:
130: The `-ansi' option prevents `alloca' and `ffs' from being builtin
131: functions, since these functions do not have an ANSI standard
132: meaning.
133:
134: `-trigraphs'
135: Support ANSI C trigraphs. You don't want to know about this
136: brain-damage. The `-ansi' option implies `-trigraphs'.
137:
138: `-traditional'
139: Attempt to support some aspects of traditional C compilers.
140: Specifically:
141:
142: * All `extern' declarations take effect globally even if they
143: are written inside of a function definition. This includes
144: implicit declarations of functions.
145:
146: * The newer keywords `typeof', `inline', `signed', `const' and
147: `volatile' are not recognized. (You can still use the
148: alternative keywords such as `__typeof__', `__inline__', and
149: so on.)
150:
151: * Comparisons between pointers and integers are always allowed.
152:
153: * Integer types `unsigned short' and `unsigned char' promote to
154: `unsigned int'.
155:
156: * Out-of-range floating point literals are not an error.
157:
158: * Certain constructs which ANSI regards as a single invalid
159: preprocessing number, such as `0xe-0xd', are treated as
160: expressions instead.
161:
162: * String "constants" are not necessarily constant; they are
163: stored in writable space, and identical looking constants are
164: allocated separately. (This is the same as the effect of
165: `-fwritable-strings'.)
166:
167: * All automatic variables not declared `register' are preserved
168: by `longjmp'. Ordinarily, GNU C follows ANSI C: automatic
169: variables not declared `volatile' may be clobbered.
170:
171: * In the preprocessor, comments convert to nothing at all,
172: rather than to a space. This allows traditional token
173: concatenation.
174:
175: * In the preprocessor, macro arguments are recognized within
176: string constants in a macro definition (and their values are
177: stringified, though without additional quote marks, when they
178: appear in such a context). The preprocessor always considers
179: a string constant to end at a newline.
180:
181: * The predefined macro `__STDC__' is not defined when you use
182: `-traditional', but `__GNUC__' is (since the GNU extensions
183: which `__GNUC__' indicates are not affected by
184: `-traditional'). If you need to write header files that work
185: differently depending on whether `-traditional' is in use, by
186: testing both of these predefined macros you can distinguish
187: four situations: GNU C, traditional GNU C, other ANSI C
188: compilers, and other old C compilers. *Note Standard
189: Predefined Macros: (cpp.info)Standard Predefined, for more
190: discussion of these and other predefined macros.
191:
192: * The preprocessor considers a string constant to end at a
193: newline (unless the newline is escaped with `\'). (Without
194: `-traditional', string constants can contain the newline
195: character as typed.)
196:
197: * The character escape sequences `\x' and `\a' evaluate as the
198: literal characters `x' and `a' respectively. Without
199: `-traditional', `\x' is a prefix for the hexadecimal
200: representation of a character, and `\a' produces a bell.
201:
202: * In C++ programs, assignment to `this' is permitted with
203: `-traditional'. (The option `-fthis-is-variable' also has
204: this effect.)
205:
206: You may wish to use `-fno-builtin' as well as `-traditional' if
207: your program uses names that are normally GNU C builtin functions
208: for other purposes of its own.
209:
210: `-traditional-cpp'
211: Attempt to support some aspects of traditional C preprocessors.
212: This includes the last three items in the table immediately above,
213: but none of the other effects of `-traditional'.
214:
215: `-fcond-mismatch'
216: Allow conditional expressions with mismatched types in the second
217: and third arguments. The value of such an expression is void.
218:
219: `-funsigned-char'
220: Let the type `char' be unsigned, like `unsigned char'.
221:
222: Each kind of machine has a default for what `char' should be. It
223: is either like `unsigned char' by default or like `signed char' by
224: default.
225:
226: Ideally, a portable program should always use `signed char' or
227: `unsigned char' when it depends on the signedness of an object.
228: But many programs have been written to use plain `char' and expect
229: it to be signed, or expect it to be unsigned, depending on the
230: machines they were written for. This option, and its inverse, let
231: you make such a program work with the opposite default.
232:
233: The type `char' is always a distinct type from each of `signed
234: char' or `unsigned char', even though its behavior is always just
235: like one of those two.
236:
237: `-fsigned-char'
238: Let the type `char' be signed, like `signed char'.
239:
240: Note that this is equivalent to `-fno-unsigned-char', which is the
241: negative form of `-funsigned-char'. Likewise, the option
242: `-fno-signed-char' is equivalent to `-funsigned-char'.
243:
244: `-fsigned-bitfields'
245: `-funsigned-bitfields'
246: `-fno-signed-bitfields'
247: `-fno-unsigned-bitfields'
248: These options control whether a bitfield is signed or unsigned,
249: when the declaration does not use either `signed' or `unsigned'.
250: By default, such a bitfield is signed, because this is consistent:
251: the basic integer types such as `int' are signed types.
252:
253: However, when `-traditional' is used, bitfields are all unsigned
254: no matter what.
255:
256: `-fwritable-strings'
257: Store string constants in the writable data segment and don't
258: uniquize them. This is for compatibility with old programs which
259: assume they can write into string constants. The option
260: `-traditional' also has this effect.
261:
262: Writing into string constants is a very bad idea; "constants"
263: should be constant.
264:
265: `-fallow-single-precision'
266: Do not promote single precision math operations to double
267: precision, even when compiling with `-traditional'.
268:
269: Traditional K&R C promotes all floating point operations to double
270: precision, regardless of the sizes of the operands. On the
271: architecture for which you are compiling, single precision may be
272: faster than double precision. If you must use `-traditional',
273: but want to use single precision operations when the operands are
274: single precision, use this option. This option has no effect
275: when compiling with ANSI or GNU C conventions (the default).
276:
277:
278: File: gcc.info, Node: C++ Dialect Options, Next: Warning Options, Prev: C Dialect Options, Up: Invoking GCC
279:
280: Options Controlling C++ Dialect
281: ===============================
282:
283: This section describes the command-line options that are only
284: meaningful for C++ programs; but you can also use most of the GNU
285: compiler options regardless of what language your program is in. For
286: example, you might compile a file `firstClass.C' like this:
287:
288: g++ -g -felide-constructors -O -c firstClass.C
289:
290: In this example, only `-felide-constructors' is an option meant only
291: for C++ programs; you can use the other options with any language
292: supported by GNU CC.
293:
294: Here is a list of options that are *only* for compiling C++ programs:
295:
296: `-fall-virtual'
297: Treat all possible member functions as virtual, implicitly. All
298: member functions (except for constructor functions and `new' or
299: `delete' member operators) are treated as virtual functions of the
300: class where they appear.
301:
302: This does not mean that all calls to these member functions will
303: be made through the internal table of virtual functions. Under
304: some circumstances, the compiler can determine that a call to a
305: given virtual function can be made directly; in these cases the
306: calls are direct in any case.
307:
308: `-fdollars-in-identifiers'
309: Accept `$' in identifiers. You can also explicitly prohibit use of
310: `$' with the option `-fno-dollars-in-identifiers'. (GNU C++
311: allows `$' by default on some target systems but not others.)
312: Traditional C allowed the character `$' to form part of
313: identifiers. However, ANSI C and C++ forbid `$' in identifiers.
314:
315: `-felide-constructors'
316: Elide constructors when this seems plausible. With this option,
317: GNU C++ initializes `y' directly from the call to `foo' without
318: going through a temporary in the following code:
319:
320: A foo ();
321: A y = foo ();
322:
323: Without this option, GNU C++ (1) initializes `y' by calling the
324: appropriate constructor for type `A'; (2) assigns the result of
325: `foo' to a temporary; and, finally, (3) replaces the initial value
326: of `y' with the temporary.
327:
328: The default behavior (`-fno-elide-constructors') is specified by
329: the draft ANSI C++ standard. If your program's constructors have
330: side effects, `-felide-constructors' can change your program's
331: behavior, since some constructor calls may be omitted.
332:
333: `-fenum-int-equiv'
334: Permit implicit conversion of `int' to enumeration types. Normally
335: GNU C++ allows conversion of `enum' to `int', but not the other
336: way around.
337:
338: `-fexternal-templates'
339: Produce smaller code for template declarations, by generating only
340: a single copy of each template function where it is defined. To
341: use this option successfully, you must also mark all files that
342: use templates with either `#pragma implementation' (the
343: definition) or `#pragma interface' (declarations). *Note
344: Declarations and Definitions in One Header: C++ Interface, for more
345: discussion of these pragmas.
346:
347: When your code is compiled with `-fexternal-templates', all
348: template instantiations are external. You must arrange for all
349: necessary instantiations to appear in the implementation file; you
350: can do this with a `typedef' that references each instantiation
351: needed. Conversely, when you compile using the default option
352: `-fno-external-templates', all template instantiations are
353: explicitly internal.
354:
355: You do not need to specify `-fexternal-templates' when compiling a
356: file that does not define and instantiate templates used in other
357: files, even if your file *uses* templates defined in other files
358: that are compiled with `-fexternal-templates'. The only side
359: effect is an increase in object size for each file that you
360: compile without `-fexternal-templates'.
361:
362: `-fmemoize-lookups'
363: `-fsave-memoized'
364: Use heuristics to compile faster. These heuristics are not
365: enabled by default, since they are only effective for certain
366: input files. Other input files compile more slowly.
367:
368: The first time the compiler must build a call to a member function
369: (or reference to a data member), it must (1) determine whether the
370: class implements member functions of that name; (2) resolve which
371: member function to call (which involves figuring out what sorts of
372: type conversions need to be made); and (3) check the visibility of
373: the member function to the caller. All of this adds up to slower
374: compilation. Normally, the second time a call is made to that
375: member function (or reference to that data member), it must go
376: through the same lengthy process again. This means that code like
377: this:
378:
379: cout << "This " << p << " has " << n << " legs.\n";
380:
381: makes six passes through all three steps. By using a software
382: cache, a "hit" significantly reduces this cost. Unfortunately,
383: using the cache introduces another layer of mechanisms which must
384: be implemented, and so incurs its own overhead.
385: `-fmemoize-lookups' enables the software cache.
386:
387: Because access privileges (visibility) to members and member
388: functions may differ from one function context to the next, G++
389: may need to flush the cache. With the `-fmemoize-lookups' flag,
390: the cache is flushed after every function that is compiled. The
391: `-fsave-memoized' flag enables the same software cache, but when
392: the compiler determines that the context of the last function
393: compiled would yield the same access privileges of the next
394: function to compile, it preserves the cache. This is most helpful
395: when defining many member functions for the same class: with the
396: exception of member functions which are friends of other classes,
397: each member function has exactly the same access privileges as
398: every other, and the cache need not be flushed.
399:
400: `-fno-strict-prototype'
401: Treat a function declaration with no arguments, such as `int foo
402: ();', as C would treat it--as saying nothing about the number of
403: arguments or their types. Normally, such a declaration in C++
404: means that the function `foo' takes no arguments.
405:
406: `-fnonnull-objects'
407: Assume that objects reached through references are not null.
408:
409: Normally, GNU C++ makes conservative assumptions about objects
410: reached through references. For example, the compiler must check
411: that `a' is not null in code like the following:
412:
413: obj &a = g ();
414: a.f (2);
415:
416: Checking that references of this sort have non-null values requires
417: extra code, however, and it is unnecessary for many programs. You
418: can use `-fnonnull-objects' to omit the checks for null, if your
419: program doesn't require checking.
420:
421: `-fthis-is-variable'
422: Permit assignment to `this'. The incorporation of user-defined
423: free store management into C++ has made assignment to `this' an
424: anachronism. Therefore, by default it is invalid to assign to
425: `this' within a class member function; that is, GNU C++ treats the
426: type of `this' in a member function of class `X' to be `X *const'.
427: However, for backwards compatibility, you can make it valid with
428: `-fthis-is-variable'.
429:
430: `-nostdinc++'
431: Do not search for header files in the standard directories
432: specific to C++, but do still search the other standard
433: directories. (This option is used when building libg++.)
434:
435: `-traditional'
436: For C++ programs (in addition to the effects that apply to both C
437: and C++), this has the same effect as `-fthis-is-variable'. *Note
438: Options Controlling C Dialect: C Dialect Options.
439:
440: In addition, these optimization, warning, and code generation options
441: have meanings only for C++ programs:
442:
443: `-fno-default-inline'
444: Do not assume `inline' for functions defined inside a class scope.
445: *Note Options That Control Optimization: Optimize Options.
446:
447: `-Wenum-clash'
448: `-Woverloaded-virtual'
449: `-Wtemplate-debugging'
450: Warnings that apply only to C++ programs. *Note Options to
451: Request or Suppress Warnings: Warning Options.
452:
453: `+eN'
454: Control how virtual function definitions are used, in a fashion
455: compatible with `cfront' 1.x. *Note Options for Code Generation
456: Conventions: Code Gen Options.
457:
458:
459: File: gcc.info, Node: Warning Options, Next: Debugging Options, Prev: C++ Dialect Options, Up: Invoking GCC
460:
461: Options to Request or Suppress Warnings
462: =======================================
463:
464: Warnings are diagnostic messages that report constructions which are
465: not inherently erroneous but which are risky or suggest there may have
466: been an error.
467:
468: You can request many specific warnings with options beginning `-W',
469: for example `-Wimplicit' to request warnings on implicit declarations.
470: Each of these specific warning options also has a negative form
471: beginning `-Wno-' to turn off warnings; for example, `-Wno-implicit'.
472: This manual lists only one of the two forms, whichever is not the
473: default.
474:
475: These options control the amount and kinds of warnings produced by
476: GNU CC:
477:
478: `-fsyntax-only'
479: Check the code for syntax errors, but don't do anything beyond
480: that.
481:
482: `-w'
483: Inhibit all warning messages.
484:
485: `-Wno-import'
486: Inhibit warning messages about the use of `#import'.
487:
488: `-pedantic'
489: Issue all the warnings demanded by strict ANSI standard C; reject
490: all programs that use forbidden extensions.
491:
492: Valid ANSI standard C programs should compile properly with or
493: without this option (though a rare few will require `-ansi').
494: However, without this option, certain GNU extensions and
495: traditional C features are supported as well. With this option,
496: they are rejected.
497:
498: `-pedantic' does not cause warning messages for use of the
499: alternate keywords whose names begin and end with `__'. Pedantic
500: warnings are also disabled in the expression that follows
501: `__extension__'. However, only system header files should use
502: these escape routes; application programs should avoid them.
503: *Note Alternate Keywords::.
504:
505: This option is not intended to be useful; it exists only to satisfy
506: pedants who would otherwise claim that GNU CC fails to support the
507: ANSI standard.
508:
509: Some users try to use `-pedantic' to check programs for strict ANSI
510: C conformance. They soon find that it does not do quite what they
511: want: it finds some non-ANSI practices, but not all--only those
512: for which ANSI C *requires* a diagnostic.
513:
514: A feature to report any failure to conform to ANSI C might be
515: useful in some instances, but would require considerable
516: additional work and would be quite different from `-pedantic'. We
517: recommend, rather, that users take advantage of the extensions of
518: GNU C and disregard the limitations of other compilers. Aside
519: from certain supercomputers and obsolete small machines, there is
520: less and less reason ever to use any other C compiler other than
521: for bootstrapping GNU CC.
522:
523: `-pedantic-errors'
524: Like `-pedantic', except that errors are produced rather than
525: warnings.
526:
527: `-W'
528: Print extra warning messages for these events:
529:
530: * A nonvolatile automatic variable might be changed by a call to
531: `longjmp'. These warnings as well are possible only in
532: optimizing compilation.
533:
534: The compiler sees only the calls to `setjmp'. It cannot know
535: where `longjmp' will be called; in fact, a signal handler
536: could call it at any point in the code. As a result, you may
537: get a warning even when there is in fact no problem because
538: `longjmp' cannot in fact be called at the place which would
539: cause a problem.
540:
541: * A function can return either with or without a value.
542: (Falling off the end of the function body is considered
543: returning without a value.) For example, this function would
544: evoke such a warning:
545:
546: foo (a)
547: {
548: if (a > 0)
549: return a;
550: }
551:
552: * An expression-statement contains no side effects.
553:
554: * An unsigned value is compared against zero with `>' or `<='.
555:
556: * A comparison like `x<=y<=z' appears; this is equivalent to
557: `(x<=y ? 1 : 0) <= z', which is a different interpretation
558: from that of ordinary mathematical notation.
559:
560: * Storage-class specifiers like `static' are not the first
561: things in a declaration. According to the C Standard, this
562: usage is obsolescent.
563:
564: * An aggregate has a partly bracketed initializer. For
565: example, the following code would evoke such a warning,
566: because braces are missing around the initializer for `x.h':
567:
568: struct s { int f, g; };
569: struct t { struct s h; int i; };
570: struct t x = { 1, 2, 3 };
571:
572: `-Wimplicit'
573: Warn whenever a function or parameter is implicitly declared.
574:
575: `-Wreturn-type'
576: Warn whenever a function is defined with a return-type that
577: defaults to `int'. Also warn about any `return' statement with no
578: return-value in a function whose return-type is not `void'.
579:
580: `-Wunused'
581: Warn whenever a local variable is unused aside from its
582: declaration, whenever a function is declared static but never
583: defined, and whenever a statement computes a result that is
584: explicitly not used.
585:
586: If you want to prevent a warning for a particular variable, you
587: can use this macro:
588:
589: #define USE(var) \
590: static void * use_##var = (&use_##var, (void *) &var)
591:
592: USE (string);
593:
594: `-Wswitch'
595: Warn whenever a `switch' statement has an index of enumeral type
596: and lacks a `case' for one or more of the named codes of that
597: enumeration. (The presence of a `default' label prevents this
598: warning.) `case' labels outside the enumeration range also
599: provoke warnings when this option is used.
600:
601: `-Wcomment'
602: Warn whenever a comment-start sequence `/*' appears in a comment.
603:
604: `-Wtrigraphs'
605: Warn if any trigraphs are encountered (assuming they are enabled).
606:
607: `-Wformat'
608: Check calls to `printf' and `scanf', etc., to make sure that the
609: arguments supplied have types appropriate to the format string
610: specified.
611:
612: `-Wchar-subscripts'
613: Warn if an array subscript has type `char'. This is a common cause
614: of error, as programmers often forget that this type is signed on
615: some machines.
616:
617: `-Wuninitialized'
618: An automatic variable is used without first being initialized.
619:
620: These warnings are possible only in optimizing compilation,
621: because they require data flow information that is computed only
622: when optimizing. If you don't specify `-O', you simply won't get
623: these warnings.
624:
625: These warnings occur only for variables that are candidates for
626: register allocation. Therefore, they do not occur for a variable
627: that is declared `volatile', or whose address is taken, or whose
628: size is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
629: structures, unions or arrays, even when they are in registers.
630:
631: Note that there may be no warning about a variable that is used
632: only to compute a value that itself is never used, because such
633: computations may be deleted by data flow analysis before the
634: warnings are printed.
635:
636: These warnings are made optional because GNU CC is not smart
637: enough to see all the reasons why the code might be correct
638: despite appearing to have an error. Here is one example of how
639: this can happen:
640:
641: {
642: int x;
643: switch (y)
644: {
645: case 1: x = 1;
646: break;
647: case 2: x = 4;
648: break;
649: case 3: x = 5;
650: }
651: foo (x);
652: }
653:
654: If the value of `y' is always 1, 2 or 3, then `x' is always
655: initialized, but GNU CC doesn't know this. Here is another common
656: case:
657:
658: {
659: int save_y;
660: if (change_y) save_y = y, y = new_y;
661: ...
662: if (change_y) y = save_y;
663: }
664:
665: This has no bug because `save_y' is used only if it is set.
666:
667: Some spurious warnings can be avoided if you declare all the
668: functions you use that never return as `volatile'. *Note Function
669: Attributes::.
670:
671: `-Wparentheses'
672: Warn if parentheses are omitted in certain contexts, such as when
673: there is an assignment in a context where a truth value is
674: expected, or when operators are nested whose precedence people
675: often get confused about.
676:
677: `-Wenum-clash'
678: Warn about conversion between different enumeration types. (C++
679: only).
680:
681: `-Wtemplate-debugging'
682: When using templates in a C++ program, warn if debugging is not yet
683: fully available (C++ only).
684:
685: `-Wall'
686: All of the above `-W' options combined. These are all the options
687: which pertain to usage that we recommend avoiding and that we
688: believe is easy to avoid, even in conjunction with macros.
689:
690: The remaining `-W...' options are not implied by `-Wall' because
691: they warn about constructions that we consider reasonable to use, on
692: occasion, in clean programs.
693:
694: `-Wtraditional'
695: Warn about certain constructs that behave differently in
696: traditional and ANSI C.
697:
698: * Macro arguments occurring within string constants in the
699: macro body. These would substitute the argument in
700: traditional C, but are part of the constant in ANSI C.
701:
702: * A function declared external in one block and then used after
703: the end of the block.
704:
705: * A `switch' statement has an operand of type `long'.
706:
707: `-Wshadow'
708: Warn whenever a local variable shadows another local variable.
709:
710: `-Wid-clash-LEN'
711: Warn whenever two distinct identifiers match in the first LEN
712: characters. This may help you prepare a program that will compile
713: with certain obsolete, brain-damaged compilers.
714:
715: `-Wpointer-arith'
716: Warn about anything that depends on the "size of" a function type
717: or of `void'. GNU C assigns these types a size of 1, for
718: convenience in calculations with `void *' pointers and pointers to
719: functions.
720:
721: `-Wcast-qual'
722: Warn whenever a pointer is cast so as to remove a type qualifier
723: from the target type. For example, warn if a `const char *' is
724: cast to an ordinary `char *'.
725:
726: `-Wcast-align'
727: Warn whenever a pointer is cast such that the required alignment
728: of the target is increased. For example, warn if a `char *' is
729: cast to an `int *' on machines where integers can only be accessed
730: at two- or four-byte boundaries.
731:
732: `-Wwrite-strings'
733: Give string constants the type `const char[LENGTH]' so that
734: copying the address of one into a non-`const' `char *' pointer
735: will get a warning. These warnings will help you find at compile
736: time code that can try to write into a string constant, but only
737: if you have been very careful about using `const' in declarations
738: and prototypes. Otherwise, it will just be a nuisance; this is
739: why we did not make `-Wall' request these warnings.
740:
741: `-Wconversion'
742: Warn if a prototype causes a type conversion that is different
743: from what would happen to the same argument in the absence of a
744: prototype. This includes conversions of fixed point to floating
745: and vice versa, and conversions changing the width or signedness
746: of a fixed point argument except when the same as the default
747: promotion.
748:
749: Also, warn if a negative integer constant expression is implicitly
750: converted to an unsigned type. For example, warn about the
751: assignment `x = -1' if `x' is unsigned. But do not warn about
752: explicit casts like `(unsigned) -1'.
753:
754: `-Waggregate-return'
755: Warn if any functions that return structures or unions are defined
756: or called. (In languages where you can return an array, this also
757: elicits a warning.)
758:
759: `-Wstrict-prototypes'
760: Warn if a function is declared or defined without specifying the
761: argument types. (An old-style function definition is permitted
762: without a warning if preceded by a declaration which specifies the
763: argument types.)
764:
765: `-Wmissing-prototypes'
766: Warn if a global function is defined without a previous prototype
767: declaration. This warning is issued even if the definition itself
768: provides a prototype. The aim is to detect global functions that
769: fail to be declared in header files.
770:
771: `-Wredundant-decls'
772: Warn if anything is declared more than once in the same scope,
773: even in cases where multiple declaration is valid and changes
774: nothing.
775:
776: `-Wnested-externs'
777: Warn if an `extern' declaration is encountered within an function.
778:
779: `-Winline'
780: Warn if a function can not be inlined, and either it was declared
781: as inline, or else the `-finline-functions' option was given.
782:
783: `-Woverloaded-virtual'
784: Warn when a derived class function declaration may be an error in
785: defining a virtual function (C++ only). In a derived class, the
786: definitions of virtual functions must match the type signature of a
787: virtual function declared in the base class. With this option, the
788: compiler warns when you define a function with the same name as a
789: virtual function, but with a type signature that does not match any
790: declarations from the base class.
791:
792: `-Werror'
793: Make all warnings into errors.
794:
795:
796: File: gcc.info, Node: Debugging Options, Next: Optimize Options, Prev: Warning Options, Up: Invoking GCC
797:
798: Options for Debugging Your Program or GNU CC
799: ============================================
800:
801: GNU CC has various special options that are used for debugging
802: either your program or GCC:
803:
804: `-g'
805: Produce debugging information in the operating system's native
806: format (stabs, COFF, XCOFF, or DWARF). GDB can work with this
807: debugging information.
808:
809: On most systems that use stabs format, `-g' enables use of extra
810: debugging information that only GDB can use; this extra information
811: makes debugging work better in GDB but will probably make other
812: debuggers crash or refuse to read the program. If you want to
813: control for certain whether to generate the extra information, use
814: `-gstabs+', `-gstabs', `-gxcoff+', `-gxcoff', `-gdwarf+', or
815: `-gdwarf' (see below).
816:
817: Unlike most other C compilers, GNU CC allows you to use `-g' with
818: `-O'. The shortcuts taken by optimized code may occasionally
819: produce surprising results: some variables you declared may not
820: exist at all; flow of control may briefly move where you did not
821: expect it; some statements may not be executed because they
822: compute constant results or their values were already at hand;
823: some statements may execute in different places because they were
824: moved out of loops.
825:
826: Nevertheless it proves possible to debug optimized output. This
827: makes it reasonable to use the optimizer for programs that might
828: have bugs.
829:
830: The following options are useful when GNU CC is generated with the
831: capability for more than one debugging format.
832:
833: `-ggdb'
834: Produce debugging information in the native format (if that is
835: supported), including GDB extensions if at all possible.
836:
837: `-gstabs'
838: Produce debugging information in stabs format (if that is
839: supported), without GDB extensions. This is the format used by
840: DBX on most BSD systems. On MIPS and Alpha systems this option
841: produces embedded stabs debugging output which is not understood
842: by DBX.
843:
844: `-gstabs+'
845: Produce debugging information in stabs format (if that is
846: supported), using GNU extensions understood only by the GNU
847: debugger (GDB). The use of these extensions is likely to make
848: other debuggers crash or refuse to read the program.
849:
850: `-gcoff'
851: Produce debugging information in COFF format (if that is
852: supported). This is the format used by SDB on most System V
853: systems prior to System V Release 4.
854:
855: `-gxcoff'
856: Produce debugging information in XCOFF format (if that is
857: supported). This is the format used by the DBX debugger on IBM
858: RS/6000 systems.
859:
860: `-gxcoff+'
861: Produce debugging information in XCOFF format (if that is
862: supported), using GNU extensions understood only by the GNU
863: debugger (GDB). The use of these extensions is likely to make
864: other debuggers crash or refuse to read the program.
865:
866: `-gdwarf'
867: Produce debugging information in DWARF format (if that is
868: supported). This is the format used by SDB on most System V
869: Release 4 systems.
870:
871: `-gdwarf+'
872: Produce debugging information in DWARF format (if that is
873: supported), using GNU extensions understood only by the GNU
874: debugger (GDB). The use of these extensions is likely to make
875: other debuggers crash or refuse to read the program.
876:
877: `-gLEVEL'
878: `-ggdbLEVEL'
879: `-gstabsLEVEL'
880: `-gcoffLEVEL'
881: `-gxcoffLEVEL'
882: `-gdwarfLEVEL'
883: Request debugging information and also use LEVEL to specify how
884: much information. The default level is 2.
885:
886: Level 1 produces minimal information, enough for making backtraces
887: in parts of the program that you don't plan to debug. This
888: includes descriptions of functions and external variables, but no
889: information about local variables and no line numbers.
890:
891: Level 3 includes extra information, such as all the macro
892: definitions present in the program. Some debuggers support macro
893: expansion when you use `-g3'.
894:
895: `-p'
896: Generate extra code to write profile information suitable for the
897: analysis program `prof'. You must use this option when compiling
898: the source files you want data about, and you must also use it when
899: linking.
900:
901: `-pg'
902: Generate extra code to write profile information suitable for the
903: analysis program `gprof'. You must use this option when compiling
904: the source files you want data about, and you must also use it when
905: linking.
906:
907: `-a'
908: Generate extra code to write profile information for basic blocks,
909: which will record the number of times each basic block is
910: executed, the basic block start address, and the function name
911: containing the basic block. If `-g' is used, the line number and
912: filename of the start of the basic block will also be recorded.
913: If not overridden by the machine description, the default action is
914: to append to the text file `bb.out'.
915:
916: This data could be analyzed by a program like `tcov'. Note,
917: however, that the format of the data is not what `tcov' expects.
918: Eventually GNU `gprof' should be extended to process this data.
919:
920: `-dLETTERS'
921: Says to make debugging dumps during compilation at times specified
922: by LETTERS. This is used for debugging the compiler. The file
923: names for most of the dumps are made by appending a word to the
924: source file name (e.g. `foo.c.rtl' or `foo.c.jump'). Here are the
925: possible letters for use in LETTERS, and their meanings:
926:
927: `M'
928: Dump all macro definitions, at the end of preprocessing, and
929: write no output.
930:
931: `N'
932: Dump all macro names, at the end of preprocessing.
933:
934: `D'
935: Dump all macro definitions, at the end of preprocessing, in
936: addition to normal output.
937:
938: `y'
939: Dump debugging information during parsing, to standard error.
940:
941: `r'
942: Dump after RTL generation, to `FILE.rtl'.
943:
944: `x'
945: Just generate RTL for a function instead of compiling it.
946: Usually used with `r'.
947:
948: `j'
949: Dump after first jump optimization, to `FILE.jump'.
950:
951: `s'
952: Dump after CSE (including the jump optimization that sometimes
953: follows CSE), to `FILE.cse'.
954:
955: `L'
956: Dump after loop optimization, to `FILE.loop'.
957:
958: `t'
959: Dump after the second CSE pass (including the jump
960: optimization that sometimes follows CSE), to `FILE.cse2'.
961:
962: `f'
963: Dump after flow analysis, to `FILE.flow'.
964:
965: `c'
966: Dump after instruction combination, to the file
967: `FILE.combine'.
968:
969: `S'
970: Dump after the first instruction scheduling pass, to
971: `FILE.sched'.
972:
973: `l'
974: Dump after local register allocation, to `FILE.lreg'.
975:
976: `g'
977: Dump after global register allocation, to `FILE.greg'.
978:
979: `R'
980: Dump after the second instruction scheduling pass, to
981: `FILE.sched2'.
982:
983: `J'
984: Dump after last jump optimization, to `FILE.jump2'.
985:
986: `d'
987: Dump after delayed branch scheduling, to `FILE.dbr'.
988:
989: `k'
990: Dump after conversion from registers to stack, to
991: `FILE.stack'.
992:
993: `a'
994: Produce all the dumps listed above.
995:
996: `m'
997: Print statistics on memory usage, at the end of the run, to
998: standard error.
999:
1000: `p'
1001: Annotate the assembler output with a comment indicating which
1002: pattern and alternative was used.
1003:
1004: `-fpretend-float'
1005: When running a cross-compiler, pretend that the target machine
1006: uses the same floating point format as the host machine. This
1007: causes incorrect output of the actual floating constants, but the
1008: actual instruction sequence will probably be the same as GNU CC
1009: would make when running on the target machine.
1010:
1011: `-save-temps'
1012: Store the usual "temporary" intermediate files permanently; place
1013: them in the current directory and name them based on the source
1014: file. Thus, compiling `foo.c' with `-c -save-temps' would produce
1015: files `foo.i' and `foo.s', as well as `foo.o'.
1016:
1017: `-print-libgcc-file-name'
1018: Print the full absolute name of the library file `libgcc.a' that
1019: would be used when linking--and don't do anything else. With this
1020: option, GNU CC does not compile or link anything; it just prints
1021: the file name.
1022:
1023: This is useful when you use `-nostdlib' but you do want to link
1024: with `libgcc.a'. You can do
1025:
1026: gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
1027:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.