gcc.html

vxworks相关论文

</P>
<P>
The following options control the dialect of C (or languages derived
from C, such as C++ and Objective C) that the compiler accepts:

</P>
<DL COMPACT>

<DT><CODE>-ansi</CODE>
<DD>
<A NAME="IDX30"></A>
 
Support all ANSI standard C programs.

This turns off certain features of GNU C that are incompatible with ANSI
C, such as the <CODE>asm</CODE>, <CODE>inline</CODE> and <CODE>typeof</CODE> keywords, and
predefined macros such as <CODE>unix</CODE> and <CODE>vax</CODE> that identify the
type of system you are using.  It also enables the undesirable and
rarely used ANSI trigraph feature, disallows <SAMP>`$'</SAMP> as part of
identifiers, and disables recognition of C++ style <SAMP>`//'</SAMP> comments.

The keywords <CODE>__asm__</CODE>, <CODE>__extension__</CODE>,
<CODE>__inline__</CODE> and <CODE>__typeof__</CODE> are alternatives that
continue to work despite <SAMP>`-ansi'</SAMP>.  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 <SAMP>`-ansi'</SAMP>.
Alternate predefined macros such as <CODE>__unix__</CODE> and <CODE>__vax__</CODE>
are also available, with or without <SAMP>`-ansi'</SAMP>.

The <SAMP>`-ansi'</SAMP> option does not cause non-ANSI programs to be
rejected gratuitously.  For that, <SAMP>`-pedantic'</SAMP> is required in
addition to <SAMP>`-ansi'</SAMP>.  See section <A HREF="gcc.html#SEC14">Options to Request or Suppress Warnings</A>.

The macro <CODE>__STRICT_ANSI__</CODE> is predefined when the <SAMP>`-ansi'</SAMP>
option is used.  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.

The functions <CODE>alloca</CODE>, <CODE>abort</CODE>, <CODE>exit</CODE>, and
<CODE>_exit</CODE> are not builtin functions when <SAMP>`-ansi'</SAMP> is used.

<DT><CODE>-fno-asm</CODE>
<DD>
Do not recognize <CODE>asm</CODE>, <CODE>inline</CODE> or <CODE>typeof</CODE> as a
keyword, so that code can use these words as identifiers.  You can use
the keywords <CODE>__asm__</CODE>, <CODE>__inline__</CODE> and <CODE>__typeof__</CODE>
instead.  <SAMP>`-ansi'</SAMP> implies <SAMP>`-fno-asm'</SAMP>.

In C++, this switch only affects the <CODE>typeof</CODE> keyword, since
<CODE>asm</CODE> and <CODE>inline</CODE> are standard keywords.  You may want to
use the <SAMP>`-fno-gnu-keywords'</SAMP> flag instead, as it also disables the
other, C++-specific, extension keywords such as <CODE>headof</CODE>.

<DT><CODE>-fno-builtin</CODE>
<DD>
<A NAME="IDX31"></A>
<A NAME="IDX32"></A>
<A NAME="IDX33"></A>
<A NAME="IDX34"></A>
<A NAME="IDX35"></A>
<A NAME="IDX36"></A>
<A NAME="IDX37"></A>
<A NAME="IDX38"></A>
<A NAME="IDX39"></A>
<A NAME="IDX40"></A>
<A NAME="IDX41"></A>
<A NAME="IDX42"></A>
<A NAME="IDX43"></A>
<A NAME="IDX44"></A>
<A NAME="IDX45"></A>
<A NAME="IDX46"></A>
Don't recognize builtin functions that do not begin with two leading
underscores.  Currently, the functions affected include <CODE>abort</CODE>,
<CODE>abs</CODE>, <CODE>alloca</CODE>, <CODE>cos</CODE>, <CODE>exit</CODE>, <CODE>fabs</CODE>,
<CODE>ffs</CODE>, <CODE>labs</CODE>, <CODE>memcmp</CODE>, <CODE>memcpy</CODE>, <CODE>sin</CODE>,
<CODE>sqrt</CODE>, <CODE>strcmp</CODE>, <CODE>strcpy</CODE>, and <CODE>strlen</CODE>.

GCC normally generates special code to handle certain builtin functions
more efficiently; for instance, calls to <CODE>alloca</CODE> may become single
instructions that adjust the stack directly, and calls to <CODE>memcpy</CODE>
may become inline copy loops.  The resulting code is often both smaller
and faster, but since the function calls no longer appear as such, you
cannot set a breakpoint on those calls, nor can you change the behavior
of the functions by linking with a different library.

The <SAMP>`-ansi'</SAMP> option prevents <CODE>alloca</CODE> and <CODE>ffs</CODE> from being
builtin functions, since these functions do not have an ANSI standard
meaning.

<DT><CODE>-trigraphs</CODE>
<DD>
Support ANSI C trigraphs.  You don't want to know about this
brain-damage.  The <SAMP>`-ansi'</SAMP> option implies <SAMP>`-trigraphs'</SAMP>.

<A NAME="IDX47"></A>
<A NAME="IDX48"></A>
<DT><CODE>-traditional</CODE>
<DD>
Attempt to support some aspects of traditional C compilers.
Specifically:


<UL>
<LI>

All <CODE>extern</CODE> declarations take effect globally even if they
are written inside of a function definition.  This includes implicit
declarations of functions.

<LI>

The newer keywords <CODE>typeof</CODE>, <CODE>inline</CODE>, <CODE>signed</CODE>, <CODE>const</CODE>
and <CODE>volatile</CODE> are not recognized.  (You can still use the
alternative keywords such as <CODE>__typeof__</CODE>, <CODE>__inline__</CODE>, and
so on.)

<LI>

Comparisons between pointers and integers are always allowed.

<LI>

Integer types <CODE>unsigned short</CODE> and <CODE>unsigned char</CODE> promote
to <CODE>unsigned int</CODE>.

<LI>

Out-of-range floating point literals are not an error.

<LI>

Certain constructs which ANSI regards as a single invalid preprocessing
number, such as <SAMP>`0xe-0xd'</SAMP>, are treated as expressions instead.

<LI>

String "constants" are not necessarily constant; they are stored in
writable space, and identical looking constants are allocated
separately.  (This is the same as the effect of
<SAMP>`-fwritable-strings'</SAMP>.)

<A NAME="IDX49"></A>
<LI>

All automatic variables not declared <CODE>register</CODE> are preserved by
<CODE>longjmp</CODE>.  Ordinarily, GNU C follows ANSI C: automatic variables
not declared <CODE>volatile</CODE> may be clobbered.

<A NAME="IDX50"></A>
<A NAME="IDX51"></A>
<A NAME="IDX52"></A>
<LI>

The character escape sequences <SAMP>`\x'</SAMP> and <SAMP>`\a'</SAMP> evaluate as the
literal characters <SAMP>`x'</SAMP> and <SAMP>`a'</SAMP> respectively.  Without
<SAMP>`-traditional'</SAMP>, <SAMP>`\x'</SAMP> is a prefix for the hexadecimal
representation of a character, and <SAMP>`\a'</SAMP> produces a bell.

<LI>

In C++ programs, assignment to <CODE>this</CODE> is permitted with
<SAMP>`-traditional'</SAMP>.  (The option <SAMP>`-fthis-is-variable'</SAMP> also has
this effect.)
</UL>

Specify <SAMP>`-fno-builtin'</SAMP> as well as <SAMP>`-traditional'</SAMP>
if your program uses names that are normally GNU C builtin functions for
other purposes of its own.

You cannot use <SAMP>`-traditional'</SAMP> if you include any header files that
rely on ANSI C features.  Some vendors are starting to ship systems with
ANSI C header files and you cannot use <SAMP>`-traditional'</SAMP> on such
systems to compile files that include any system headers.

<DT><CODE></CODE>
<DD>
In the preprocessor, comments convert to nothing at all, rather than
to a space.  This allows traditional token concatenation.

<DT><CODE></CODE>
<DD>
In preprocessing directive, the <SAMP>`#'</SAMP> symbol must appear as the first
character of a line.

<DT><CODE></CODE>
<DD>
In the preprocessor, macro arguments are recognized within string
constants in a macro definition (and their values are stringified,
though without additional quote marks, when they appear in such a
context).  The preprocessor always considers a string constant to end
at a newline.

<A NAME="IDX53"></A>
<DT><CODE></CODE>
<DD>
The predefined macro <CODE>__STDC__</CODE> is not defined when you use
<SAMP>`-traditional'</SAMP>, but <CODE>__GNUC__</CODE> is (since the GNU extensions
which <CODE>__GNUC__</CODE> indicates are not affected by
<SAMP>`-traditional'</SAMP>).  If you need to write header files that work
differently depending on whether <SAMP>`-traditional'</SAMP> is in use, by
testing both of these predefined macros you can distinguish four
situations: GNU C, traditional GNU C, other ANSI C compilers, and other
old C compilers.  The predefined macro <CODE>__STDC_VERSION__</CODE> is also
not defined when you use <SAMP>`-traditional'</SAMP>.  See section `Standard Predefined Macros' in <CITE>The C Preprocessor</CITE>,
for more discussion of these and other predefined macros.

<A NAME="IDX54"></A>
<A NAME="IDX55"></A>
<DT><CODE></CODE>
<DD>
The preprocessor considers a string constant to end at a newline (unless
the newline is escaped with <SAMP>`\'</SAMP>).  (Without <SAMP>`-traditional'</SAMP>,
string constants can contain the newline character as typed.)

<DT><CODE>-traditional-cpp</CODE>
<DD>
Attempt to support some aspects of traditional C preprocessors.
This includes the last five items in the table immediately above,
but none of the other effects of <SAMP>`-traditional'</SAMP>.

<DT><CODE>-fcond-mismatch</CODE>
<DD>
Allow conditional expressions with mismatched types in the second and
third arguments.  The value of such an expression is void.

<DT><CODE>-funsigned-char</CODE>
<DD>
Let the type <CODE>char</CODE> be unsigned, like <CODE>unsigned char</CODE>.

Each kind of machine has a default for what <CODE>char</CODE> should
be.  It is either like <CODE>unsigned char</CODE> by default or like
<CODE>signed char</CODE> by default.

Ideally, a portable program should always use <CODE>signed char</CODE> or
<CODE>unsigned char</CODE> when it depends on the signedness of an object.
But many programs have been written to use plain <CODE>char</CODE> 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 <CODE>char</CODE> is always a distinct type from each of
<CODE>signed char</CODE> or <CODE>unsigned char</CODE>, even though its behavior
is always just like one of those two.

<DT><CODE>-fsigned-char</CODE>
<DD>
Let the type <CODE>char</CODE> be signed, like <CODE>signed char</CODE>.

Note that this is equivalent to <SAMP>`-fno-unsigned-char'</SAMP>, which is
the negative form of <SAMP>`-funsigned-char'</SAMP>.  Likewise, the option
<SAMP>`-fno-signed-char'</SAMP> is equivalent to <SAMP>`-funsigned-char'</SAMP>.

<DT><CODE>-fsigned-bitfields</CODE>
<DD>
<DT><CODE>-funsigned-bitfields</CODE>
<DD>
<DT><CODE>-fno-signed-bitfields</CODE>
<DD>
<DT><CODE>-fno-unsigned-bitfields</CODE>
<DD>
These options control whether a bitfield is signed or unsigned, when the
declaration does not use either <CODE>signed</CODE> or <CODE>unsigned</CODE>.  By
default, such a bitfield is signed, because this is consistent: the
basic integer types such as <CODE>int</CODE> are signed types.

However, when <SAMP>`-traditional'</SAMP> is used, bitfields are all unsigned
no matter what.

<DT><CODE>-fwritable-strings</CODE>
<DD>
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.  The option <SAMP>`-traditional'</SAMP> also has
this effect.

Writing into string constants is a very bad idea; "constants" should
be constant.

<DT><CODE>-fallow-single-precision</CODE>
<DD>
Do not promote single precision math operations to double precision,
even when compiling with <SAMP>`-traditional'</SAMP>.

Traditional K&#38;R C promotes all floating point operations to double
precision, regardless of the sizes of the operands.   On the
architecture for which you are compiling, single precision may be faster
than double precision.   If you must use <SAMP>`-traditional'</SAMP>, but want
to use single precision operations when the operands are single
precision, use this option.   This option has no effect when compiling
with ANSI or GNU C conventions (the default).

</DL>



<H2><A NAME="SEC13" HREF="gcc_toc.html#TOC13">Options Controlling C++ Dialect</A></H2>

<P>
<A NAME="IDX56"></A>
<A NAME="IDX57"></A>
<A NAME="IDX58"></A>
This section describes the command-line options that are only meaningful
for C++ programs; but you can also use most of the GNU compiler options
regardless of what language your program is in.  For example, you
might compile a file <CODE>firstClass.C</CODE> like this:

</P>

<PRE>
g++ -g -felide-constructors -O -c firstClass.C
</PRE>

<P>
In this example, only <SAMP>`-felide-constructors'</SAMP> is an option meant
only for C++ programs; you can use the other options with any
language supported by GNU CC.

</P>
<P>
Here is a list of options that are <EM>only</EM> for compiling C++ programs:

</P>
<DL COMPACT>

<DT><CODE>-fno-access-control</CODE>
<DD>
Turn off all access checking.  This switch is mainly useful for working
around bugs in the access control code.

<DT><CODE>-fall-virtual</CODE>
<DD>
Treat all possible member functions as virtual, implicitly.
All member functions (except for constructor functions and <CODE>new</CODE> or
<CODE>delete</CODE> member operators) are treated as virtual functions of the
class where they appear.

This does not mean that all calls to these member functions will be made
through the internal table of virtual functions.  Under some
circumstances, the compiler can determine that a call to a given virtual
function can be made directly; in these cases the calls are direct in
any case.

<DT><CODE>-fcheck-new</CODE>
<DD>
Check that the pointer returned by <CODE>operator new</CODE> is non-null
before attempting to modify the storage allocated.  The current Working
Paper requires that <CODE>operator new</CODE> never return a null pointer, so
this check is normally unnecessary.

<DT><CODE>-fconserve-space</CODE>
<DD>
Put uninitialized or runtime-initialized global variables into the
common segment, as C does.  This saves space in the executable at the
cost of not diagnosing duplicate definitions.  If you compile with this
flag and your program mysteriously crashes after <CODE>main()</CODE> has
completed, you may have an object that is being destroyed twice because
two definitions were merged.

<DT><CODE>-fdollars-in-identifiers</CODE>
<DD>
Accept <SAMP>`$'</SAMP> in identifiers.  You can also explicitly prohibit use of
<S