2344 lines
108 KiB
HTML
2344 lines
108 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 17 2001 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Using and Porting the GNU Compiler Collection (GCC): Trouble</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): Trouble">
|
|
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): Trouble">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC118"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC117" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC117"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC119" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC119"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 7. Known Causes of Trouble with GCC </H1>
|
|
<!--docid::SEC118::-->
|
|
<P>
|
|
|
|
This section describes known problems that affect users of GCC. Most
|
|
of these are not GCC bugs per se--if they were, we would fix them.
|
|
But the result for a user may be like the result of a bug.
|
|
</P><P>
|
|
|
|
Some of these problems are due to bugs in other software, some are
|
|
missing features that are too much work to add, and some are places
|
|
where people's opinions differ as to what is best.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC119" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC119">7.1 Actual Bugs We Haven't Fixed Yet</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Bugs we will fix later.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120">7.2 Installation Problems</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Problems that manifest when you install GCC.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC121" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC121">7.3 Cross-Compiler Problems</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Common problems of cross compiling with GCC.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC122" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC122">7.4 Interoperation</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Problems using GCC with other compilers,
|
|
and with certain linkers, assemblers and debuggers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC123" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC123">7.5 Problems Compiling Certain Programs</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Problems compiling certain programs.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC124" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC124">7.6 Incompatibilities of GCC</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">GCC is incompatible with traditional C.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC125" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC125">7.7 Fixed Header Files</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">GNU C uses corrected versions of system header files.
|
|
This is necessary, but doesn't always work smoothly.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC126" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC126">7.8 Standard Libraries</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">GNU C uses the system C library, which might not be
|
|
compliant with the ISO/ANSI C standard.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC127" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC127">7.9 Disappointments and Misunderstandings</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Regrettable things we can't change, but not quite bugs.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC128" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC128">7.10 Common Misunderstandings with GNU C++</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Common misunderstandings with GNU C++.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132">7.11 Caveats of using <CODE>protoize</CODE></A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Things to watch out for when using <CODE>protoize</CODE>.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC133" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC133">7.12 Certain Changes We Don't Want to Make</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Things we think are right, but some others disagree.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC134" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC134">7.13 Warning Messages and Error Messages</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Which problems in your code get warnings,
|
|
and which get errors.</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Actual Bugs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC119"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.1 Actual Bugs We Haven't Fixed Yet </H2>
|
|
<!--docid::SEC119::-->
|
|
<P>
|
|
|
|
<UL>
|
|
<LI>
|
|
The <CODE>fixincludes</CODE> script interacts badly with automounters; if the
|
|
directory of system header files is automounted, it tends to be
|
|
unmounted while <CODE>fixincludes</CODE> is running. This would seem to be a
|
|
bug in the automounter. We don't know any good way to work around it.
|
|
<P>
|
|
|
|
<LI>
|
|
The <CODE>fixproto</CODE> script will sometimes add prototypes for the
|
|
<CODE>sigsetjmp</CODE> and <CODE>siglongjmp</CODE> functions that reference the
|
|
<CODE>jmp_buf</CODE> type before that type is defined. To work around this,
|
|
edit the offending file and place the typedef in front of the
|
|
prototypes.
|
|
<P>
|
|
|
|
<LI>
|
|
There are several obscure case of mis-using struct, union, and
|
|
enum tags that are not detected as errors by the compiler.
|
|
<P>
|
|
|
|
<LI>
|
|
When <SAMP>`-pedantic-errors'</SAMP> is specified, GCC will incorrectly give
|
|
an error message when a function name is specified in an expression
|
|
involving the comma operator.
|
|
<P>
|
|
|
|
<LI>
|
|
Loop unrolling doesn't work properly for certain C++ programs. This is
|
|
a bug in the C++ front end. It sometimes emits incorrect debug info, and
|
|
the loop unrolling code is unable to recover from this error.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Installation Problems"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC120"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC119" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC119"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC121" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC121"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC121" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC121"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.2 Installation Problems </H2>
|
|
<!--docid::SEC120::-->
|
|
<P>
|
|
|
|
This is a list of problems (and some apparent problems which don't
|
|
really mean anything is wrong) that show up during installation of GNU
|
|
CC.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
On certain systems, defining certain environment variables such as
|
|
<CODE>CC</CODE> can interfere with the functioning of <CODE>make</CODE>.
|
|
<P>
|
|
|
|
<LI>
|
|
If you encounter seemingly strange errors when trying to build the
|
|
compiler in a directory other than the source directory, it could be
|
|
because you have previously configured the compiler in the source
|
|
directory. Make sure you have done all the necessary preparations.
|
|
See section <A HREF="gcc_3.html#SEC49" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html#SEC49">3.3 Compilation in a Separate Directory</A>.
|
|
<P>
|
|
|
|
<LI>
|
|
If you build GCC on a BSD system using a directory stored in a System
|
|
V file system, problems may occur in running <CODE>fixincludes</CODE> if the
|
|
System V file system doesn't support symbolic links. These problems
|
|
result in a failure to fix the declaration of <CODE>size_t</CODE> in
|
|
<TT>`sys/types.h'</TT>. If you find that <CODE>size_t</CODE> is a signed type and
|
|
that type mismatches occur, this could be the cause.
|
|
<P>
|
|
|
|
The solution is not to use such a directory for building GCC.
|
|
</P><P>
|
|
|
|
<LI>
|
|
In previous versions of GCC, the <CODE>gcc</CODE> driver program looked for
|
|
<CODE>as</CODE> and <CODE>ld</CODE> in various places; for example, in files
|
|
beginning with <TT>`/usr/local/lib/gcc-'</TT>. GCC version 2 looks for
|
|
them in the directory
|
|
<TT>`/usr/local/lib/gcc-lib/<VAR>target</VAR>/<VAR>version</VAR>'</TT>.
|
|
<P>
|
|
|
|
Thus, to use a version of <CODE>as</CODE> or <CODE>ld</CODE> that is not the system
|
|
default, for example <CODE>gas</CODE> or GNU <CODE>ld</CODE>, you must put them in
|
|
that directory (or make links to them from that directory).
|
|
</P><P>
|
|
|
|
<LI>
|
|
Some commands executed when making the compiler may fail (return a
|
|
non-zero status) and be ignored by <CODE>make</CODE>. These failures, which
|
|
are often due to files that were not found, are expected, and can safely
|
|
be ignored.
|
|
<P>
|
|
|
|
<LI>
|
|
It is normal to have warnings in compiling certain files about
|
|
unreachable code and about enumeration type clashes. These files' names
|
|
begin with <SAMP>`insn-'</SAMP>. Also, <TT>`real.c'</TT> may get some warnings that
|
|
you can ignore.
|
|
<P>
|
|
|
|
<LI>
|
|
Sometimes <CODE>make</CODE> recompiles parts of the compiler when installing
|
|
the compiler. In one case, this was traced down to a bug in
|
|
<CODE>make</CODE>. Either ignore the problem or switch to GNU Make.
|
|
<P>
|
|
|
|
<LI>
|
|
If you have installed a program known as purify, you may find that it
|
|
causes errors while linking <CODE>enquire</CODE>, which is part of building
|
|
GCC. The fix is to get rid of the file <CODE>real-ld</CODE> which purify
|
|
installs--so that GCC won't try to use it.
|
|
<P>
|
|
|
|
<LI>
|
|
On GNU/Linux SLS 1.01, there is a problem with <TT>`libc.a'</TT>: it does not
|
|
contain the obstack functions. However, GCC assumes that the obstack
|
|
functions are in <TT>`libc.a'</TT> when it is the GNU C library. To work
|
|
around this problem, change the <CODE>__GNU_LIBRARY__</CODE> conditional
|
|
around line 31 to <SAMP>`#if 1'</SAMP>.
|
|
<P>
|
|
|
|
<LI>
|
|
On some 386 systems, building the compiler never finishes because
|
|
<CODE>enquire</CODE> hangs due to a hardware problem in the motherboard--it
|
|
reports floating point exceptions to the kernel incorrectly. You can
|
|
install GCC except for <TT>`float.h'</TT> by patching out the command to
|
|
run <CODE>enquire</CODE>. You may also be able to fix the problem for real by
|
|
getting a replacement motherboard. This problem was observed in
|
|
Revision E of the Micronics motherboard, and is fixed in Revision F.
|
|
It has also been observed in the MYLEX MXA-33 motherboard.
|
|
<P>
|
|
|
|
If you encounter this problem, you may also want to consider removing
|
|
the FPU from the socket during the compilation. Alternatively, if you
|
|
are running SCO Unix, you can reboot and force the FPU to be ignored.
|
|
To do this, type <SAMP>`hd(40)unix auto ignorefpu'</SAMP>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On some 386 systems, GCC crashes trying to compile <TT>`enquire.c'</TT>.
|
|
This happens on machines that don't have a 387 FPU chip. On 386
|
|
machines, the system kernel is supposed to emulate the 387 when you
|
|
don't have one. The crash is due to a bug in the emulator.
|
|
<P>
|
|
|
|
One of these systems is the Unix from Interactive Systems: 386/ix.
|
|
On this system, an alternate emulator is provided, and it does work.
|
|
To use it, execute this command as super-user:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>ln /etc/emulator.rel1 /etc/emulator
|
|
</pre></td></tr></table></P><P>
|
|
|
|
and then reboot the system. (The default emulator file remains present
|
|
under the name <TT>`emulator.dflt'</TT>.)
|
|
</P><P>
|
|
|
|
Try using <TT>`/etc/emulator.att'</TT>, if you have such a problem on the
|
|
SCO system.
|
|
</P><P>
|
|
|
|
Another system which has this problem is Esix. We don't know whether it
|
|
has an alternate emulator that works.
|
|
</P><P>
|
|
|
|
On NetBSD 0.8, a similar problem manifests itself as these error messages:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>enquire.c: In function `fprop':
|
|
enquire.c:2328: floating overflow
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
On SCO systems, when compiling GCC with the system's compiler,
|
|
do not use <SAMP>`-O'</SAMP>. Some versions of the system's compiler miscompile
|
|
GCC with <SAMP>`-O'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX360"></A>
|
|
<LI>
|
|
Sometimes on a Sun 4 you may observe a crash in the program
|
|
<CODE>genflags</CODE> or <CODE>genoutput</CODE> while building GCC. This is said to
|
|
be due to a bug in <CODE>sh</CODE>. You can probably get around it by running
|
|
<CODE>genflags</CODE> or <CODE>genoutput</CODE> manually and then retrying the
|
|
<CODE>make</CODE>.
|
|
<P>
|
|
|
|
<LI>
|
|
On Solaris 2, executables of GCC version 2.0.2 are commonly
|
|
available, but they have a bug that shows up when compiling current
|
|
versions of GCC: undefined symbol errors occur during assembly if you
|
|
use <SAMP>`-g'</SAMP>.
|
|
<P>
|
|
|
|
The solution is to compile the current version of GCC without
|
|
<SAMP>`-g'</SAMP>. That makes a working compiler which you can use to recompile
|
|
with <SAMP>`-g'</SAMP>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Solaris 2 comes with a number of optional OS packages. Some of these
|
|
packages are needed to use GCC fully. If you did not install all
|
|
optional packages when installing Solaris, you will need to verify that
|
|
the packages that GCC needs are installed.
|
|
<P>
|
|
|
|
To check whether an optional package is installed, use
|
|
the <CODE>pkginfo</CODE> command. To add an optional package, use the
|
|
<CODE>pkgadd</CODE> command. For further details, see the Solaris
|
|
documentation.
|
|
</P><P>
|
|
|
|
For Solaris 2.0 and 2.1, GCC needs six packages: <SAMP>`SUNWarc'</SAMP>,
|
|
<SAMP>`SUNWbtool'</SAMP>, <SAMP>`SUNWesu'</SAMP>, <SAMP>`SUNWhea'</SAMP>, <SAMP>`SUNWlibm'</SAMP>, and
|
|
<SAMP>`SUNWtoo'</SAMP>.
|
|
</P><P>
|
|
|
|
For Solaris 2.2, GCC needs an additional seventh package: <SAMP>`SUNWsprot'</SAMP>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On Solaris 2, trying to use the linker and other tools in
|
|
<TT>`/usr/ucb'</TT> to install GCC has been observed to cause trouble.
|
|
For example, the linker may hang indefinitely. The fix is to remove
|
|
<TT>`/usr/ucb'</TT> from your <CODE>PATH</CODE>.
|
|
<P>
|
|
|
|
<LI>
|
|
If you use the 1.31 version of the MIPS assembler (such as was shipped
|
|
with Ultrix 3.1), you will need to use the -fno-delayed-branch switch
|
|
when optimizing floating point code. Otherwise, the assembler will
|
|
complain when the GCC compiler fills a branch delay slot with a
|
|
floating point instruction, such as <CODE>add.d</CODE>.
|
|
<P>
|
|
|
|
<LI>
|
|
If on a MIPS system you get an error message saying "does not have gp
|
|
sections for all it's [sic] sectons [sic]", don't worry about it. This
|
|
happens whenever you use GAS with the MIPS linker, but there is not
|
|
really anything wrong, and it is okay to use the output file. You can
|
|
stop such warnings by installing the GNU linker.
|
|
<P>
|
|
|
|
It would be nice to extend GAS to produce the gp tables, but they are
|
|
optional, and there should not be a warning about their absence.
|
|
</P><P>
|
|
|
|
<LI>
|
|
In Ultrix 4.0 on the MIPS machine, <TT>`stdio.h'</TT> does not work with GNU
|
|
CC at all unless it has been fixed with <CODE>fixincludes</CODE>. This causes
|
|
problems in building GCC. Once GCC is installed, the problems go
|
|
away.
|
|
<P>
|
|
|
|
To work around this problem, when making the stage 1 compiler, specify
|
|
this option to Make:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>GCC_FOR_TARGET="./xgcc -B./ -I./include"
|
|
</pre></td></tr></table></P><P>
|
|
|
|
When making stage 2 and stage 3, specify this option:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>CFLAGS="-g -I./include"
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
Users have reported some problems with version 2.0 of the MIPS
|
|
compiler tools that were shipped with Ultrix 4.1. Version 2.10
|
|
which came with Ultrix 4.2 seems to work fine.
|
|
<P>
|
|
|
|
Users have also reported some problems with version 2.20 of the
|
|
MIPS compiler tools that were shipped with RISC/os 4.x. The earlier
|
|
version 2.11 seems to work fine.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Some versions of the MIPS linker will issue an assertion failure
|
|
when linking code that uses <CODE>alloca</CODE> against shared
|
|
libraries on RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug
|
|
in the linker, that is supposed to be fixed in future revisions.
|
|
To protect against this, GCC passes <SAMP>`-non_shared'</SAMP> to the
|
|
linker unless you pass an explicit <SAMP>`-shared'</SAMP> or
|
|
<SAMP>`-call_shared'</SAMP> switch.
|
|
<P>
|
|
|
|
<LI>
|
|
On System V release 3, you may get this error message
|
|
while linking:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>ld fatal: failed to write symbol name <VAR>something</VAR>
|
|
in strings table for file <VAR>whatever</VAR>
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
This probably indicates that the disk is full or your ULIMIT won't allow
|
|
the file to be as large as it needs to be.
|
|
</P><P>
|
|
|
|
This problem can also result because the kernel parameter <CODE>MAXUMEM</CODE>
|
|
is too small. If so, you must regenerate the kernel and make the value
|
|
much larger. The default value is reported to be 1024; a value of 32768
|
|
is said to work. Smaller values may also work.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On System V, if you get an error like this,
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>/usr/local/lib/bison.simple: In function `yyparse':
|
|
/usr/local/lib/bison.simple:625: virtual memory exhausted
|
|
</pre></td></tr></table></P><P>
|
|
|
|
that too indicates a problem with disk space, ULIMIT, or <CODE>MAXUMEM</CODE>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Current GCC versions probably do not work on version 2 of the NeXT
|
|
operating system.
|
|
<P>
|
|
|
|
<LI>
|
|
On NeXTStep 3.0, the Objective C compiler does not work, due,
|
|
apparently, to a kernel bug that it happens to trigger. This problem
|
|
does not happen on 3.1.
|
|
<P>
|
|
|
|
<LI>
|
|
On the Tower models 4<VAR>n</VAR>0 and 6<VAR>n</VAR>0, by default a process is not
|
|
allowed to have more than one megabyte of memory. GCC cannot compile
|
|
itself (or many other programs) with <SAMP>`-O'</SAMP> in that much memory.
|
|
<P>
|
|
|
|
To solve this problem, reconfigure the kernel adding the following line
|
|
to the configuration file:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>MAXUMEM = 4096
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug
|
|
in the assembler that must be fixed before GCC can be built. This
|
|
bug manifests itself during the first stage of compilation, while
|
|
building <TT>`libgcc2.a'</TT>:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>_floatdisf
|
|
cc1: warning: `-g' option not supported on this version of GCC
|
|
cc1: warning: `-g1' option not supported on this version of GCC
|
|
./xgcc: Internal compiler error: program as got fatal signal 11
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
A patched version of the assembler is available by anonymous ftp from
|
|
<CODE>altdorf.ai.mit.edu</CODE> as the file
|
|
<TT>`archive/cph/hpux-8.0-assembler'</TT>. If you have HP software support,
|
|
the patch can also be obtained directly from HP, as described in the
|
|
following note:
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE>
|
|
This is the patched assembler, to patch SR#1653-010439, where the
|
|
assembler aborts on floating point constants.
|
|
<P>
|
|
|
|
The bug is not really in the assembler, but in the shared library
|
|
version of the function "cvtnum(3c)". The bug on "cvtnum(3c)" is
|
|
SR#4701-078451. Anyway, the attached assembler uses the archive
|
|
library version of "cvtnum(3c)" and thus does not exhibit the bug.
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
|
|
This patch is also known as PHCO_4484.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On HP-UX version 8.05, but not on 8.07 or more recent versions,
|
|
the <CODE>fixproto</CODE> shell script triggers a bug in the system shell.
|
|
If you encounter this problem, upgrade your operating system or
|
|
use BASH (the GNU shell) to run <CODE>fixproto</CODE>.
|
|
<P>
|
|
|
|
<LI>
|
|
Some versions of the Pyramid C compiler are reported to be unable to
|
|
compile GCC. You must use an older version of GCC for
|
|
bootstrapping. One indication of this problem is if you get a crash
|
|
when GCC compiles the function <CODE>muldi3</CODE> in file <TT>`libgcc2.c'</TT>.
|
|
<P>
|
|
|
|
You may be able to succeed by getting GCC version 1, installing it,
|
|
and using it to compile GCC version 2. The bug in the Pyramid C
|
|
compiler does not seem to affect GCC version 1.
|
|
</P><P>
|
|
|
|
<LI>
|
|
There may be similar problems on System V Release 3.1 on 386 systems.
|
|
<P>
|
|
|
|
<LI>
|
|
On the Intel Paragon (an i860 machine), if you are using operating
|
|
system version 1.0, you will get warnings or errors about redefinition
|
|
of <CODE>va_arg</CODE> when you build GCC.
|
|
<P>
|
|
|
|
If this happens, then you need to link most programs with the library
|
|
<TT>`iclib.a'</TT>. You must also modify <TT>`stdio.h'</TT> as follows: before
|
|
the lines
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#if defined(__i860__) && !defined(_VA_LIST)
|
|
#include <va_list.h>
|
|
</pre></td></tr></table></P><P>
|
|
|
|
insert the line
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#if __PGC__
|
|
</pre></td></tr></table></P><P>
|
|
|
|
and after the lines
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>extern int vprintf(const char *, va_list );
|
|
extern int vsprintf(char *, const char *, va_list );
|
|
#endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
insert the line
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#endif /* __PGC__ */
|
|
</pre></td></tr></table></P><P>
|
|
|
|
These problems don't exist in operating system version 1.1.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On the Altos 3068, programs compiled with GCC won't work unless you
|
|
fix a kernel bug. This happens using system versions V.2.2 1.0gT1 and
|
|
V.2.2 1.0e and perhaps later versions as well. See the file
|
|
<TT>`README.ALTOS'</TT>.
|
|
<P>
|
|
|
|
<LI>
|
|
You will get several sorts of compilation and linking errors on the
|
|
we32k if you don't follow the special instructions. See section <A HREF="gcc_3.html#SEC48" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html#SEC48">3.2 Configurations Supported by GNU CC</A>.
|
|
<P>
|
|
|
|
<LI>
|
|
A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
|
|
program to report an error of the form:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>./fixproto: sh internal 1K buffer overflow
|
|
</pre></td></tr></table></P><P>
|
|
|
|
To fix this, change the first line of the fixproto script to look like:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#!/bin/ksh
|
|
</pre></td></tr></table></UL>
|
|
<P>
|
|
|
|
<A NAME="Cross-Compiler Problems"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC121"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC122" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC122"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC122" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC122"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.3 Cross-Compiler Problems </H2>
|
|
<!--docid::SEC121::-->
|
|
<P>
|
|
|
|
You may run into problems with cross compilation on certain machines,
|
|
for several reasons.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Cross compilation can run into trouble for certain machines because
|
|
some target machines' assemblers require floating point numbers to be
|
|
written as <EM>integer</EM> constants in certain contexts.
|
|
<P>
|
|
|
|
The compiler writes these integer constants by examining the floating
|
|
point value as an integer and printing that integer, because this is
|
|
simple to write and independent of the details of the floating point
|
|
representation. But this does not work if the compiler is running on
|
|
a different machine with an incompatible floating point format, or
|
|
even a different byte-ordering.
|
|
</P><P>
|
|
|
|
In addition, correct constant folding of floating point values
|
|
requires representing them in the target machine's format.
|
|
(The C standard does not quite require this, but in practice
|
|
it is the only way to win.)
|
|
</P><P>
|
|
|
|
It is now possible to overcome these problems by defining macros such
|
|
as <CODE>REAL_VALUE_TYPE</CODE>. But doing so is a substantial amount of
|
|
work for each target machine.
|
|
See section <A HREF="gcc_17.html#SEC249" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC249">17.18 Cross Compilation and Floating Point</A>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
At present, the program <TT>`mips-tfile'</TT> which adds debug
|
|
support to object files on MIPS systems does not work in a cross
|
|
compile environment.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Interoperation"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC122"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC121" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC121"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC123" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC123"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC123" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC123"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.4 Interoperation </H2>
|
|
<!--docid::SEC122::-->
|
|
<P>
|
|
|
|
This section lists various difficulties encountered in using GNU C or
|
|
GNU C++ together with other compilers or with the assemblers, linkers,
|
|
libraries and debuggers on certain systems.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Objective C does not work on the RS/6000.
|
|
<P>
|
|
|
|
<LI>
|
|
GNU C++ does not do name mangling in the same way as other C++
|
|
compilers. This means that object files compiled with one compiler
|
|
cannot be used with another.
|
|
<P>
|
|
|
|
This effect is intentional, to protect you from more subtle problems.
|
|
Compilers differ as to many internal details of C++ implementation,
|
|
including: how class instances are laid out, how multiple inheritance is
|
|
implemented, and how virtual function calls are handled. If the name
|
|
encoding were made the same, your programs would link against libraries
|
|
provided from other compilers--but the programs would then crash when
|
|
run. Incompatible libraries are then detected at link time, rather than
|
|
at run time.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Older GDB versions sometimes fail to read the output of GCC version
|
|
2. If you have trouble, get GDB version 4.4 or later.
|
|
<P>
|
|
|
|
<LI>
|
|
<A NAME="IDX361"></A>
|
|
DBX rejects some files produced by GCC, though it accepts similar
|
|
constructs in output from PCC. Until someone can supply a coherent
|
|
description of what is valid DBX input and what is not, there is
|
|
nothing I can do about these problems. You are on your own.
|
|
<P>
|
|
|
|
<LI>
|
|
The GNU assembler (GAS) does not support PIC. To generate PIC code, you
|
|
must use some other assembler, such as <TT>`/bin/as'</TT>.
|
|
<P>
|
|
|
|
<LI>
|
|
On some BSD systems, including some versions of Ultrix, use of profiling
|
|
causes static variable destructors (currently used only in C++) not to
|
|
be run.
|
|
<P>
|
|
|
|
<LI>
|
|
Use of <SAMP>`-I/usr/include'</SAMP> may cause trouble.
|
|
<P>
|
|
|
|
Many systems come with header files that won't work with GCC unless
|
|
corrected by <CODE>fixincludes</CODE>. The corrected header files go in a new
|
|
directory; GCC searches this directory before <TT>`/usr/include'</TT>.
|
|
If you use <SAMP>`-I/usr/include'</SAMP>, this tells GCC to search
|
|
<TT>`/usr/include'</TT> earlier on, before the corrected headers. The
|
|
result is that you get the uncorrected header files.
|
|
</P><P>
|
|
|
|
Instead, you should use these options (when compiling C programs):
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>-I/usr/local/lib/gcc-lib/<VAR>target</VAR>/<VAR>version</VAR>/include -I/usr/include
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
For C++ programs, GCC also uses a special directory that defines C++
|
|
interfaces to standard C subroutines. This directory is meant to be
|
|
searched <EM>before</EM> other standard include directories, so that it
|
|
takes precedence. If you are compiling C++ programs and specifying
|
|
include directories explicitly, use this option first, then the two
|
|
options above:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>-I/usr/local/lib/g++-include
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
On some SGI systems, when you use <SAMP>`-lgl_s'</SAMP> as an option,
|
|
it gets translated magically to <SAMP>`-lgl_s -lX11_s -lc_s'</SAMP>.
|
|
Naturally, this does not happen when you use GCC.
|
|
You must specify all three options explicitly.
|
|
<P>
|
|
|
|
<LI>
|
|
On a Sparc, GCC aligns all values of type <CODE>double</CODE> on an 8-byte
|
|
boundary, and it expects every <CODE>double</CODE> to be so aligned. The Sun
|
|
compiler usually gives <CODE>double</CODE> values 8-byte alignment, with one
|
|
exception: function arguments of type <CODE>double</CODE> may not be aligned.
|
|
<P>
|
|
|
|
As a result, if a function compiled with Sun CC takes the address of an
|
|
argument of type <CODE>double</CODE> and passes this pointer of type
|
|
<CODE>double *</CODE> to a function compiled with GCC, dereferencing the
|
|
pointer may cause a fatal signal.
|
|
</P><P>
|
|
|
|
One way to solve this problem is to compile your entire program with GNU
|
|
CC. Another solution is to modify the function that is compiled with
|
|
Sun CC to copy the argument into a local variable; local variables
|
|
are always properly aligned. A third solution is to modify the function
|
|
that uses the pointer to dereference it via the following function
|
|
<CODE>access_double</CODE> instead of directly with <SAMP>`*'</SAMP>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>inline double
|
|
access_double (double *unaligned_ptr)
|
|
{
|
|
union d2i { double d; int i[2]; };
|
|
|
|
union d2i *p = (union d2i *) unaligned_ptr;
|
|
union d2i u;
|
|
|
|
u.i[0] = p->i[0];
|
|
u.i[1] = p->i[1];
|
|
|
|
return u.d;
|
|
}
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
Storing into the pointer can be done likewise with the same union.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On Solaris, the <CODE>malloc</CODE> function in the <TT>`libmalloc.a'</TT> library
|
|
may allocate memory that is only 4 byte aligned. Since GCC on the
|
|
Sparc assumes that doubles are 8 byte aligned, this may result in a
|
|
fatal signal if doubles are stored in memory allocated by the
|
|
<TT>`libmalloc.a'</TT> library.
|
|
<P>
|
|
|
|
The solution is to not use the <TT>`libmalloc.a'</TT> library. Use instead
|
|
<CODE>malloc</CODE> and related functions from <TT>`libc.a'</TT>; they do not have
|
|
this problem.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Sun forgot to include a static version of <TT>`libdl.a'</TT> with some
|
|
versions of SunOS (mainly 4.1). This results in undefined symbols when
|
|
linking static binaries (that is, if you use <SAMP>`-static'</SAMP>). If you
|
|
see undefined symbols <CODE>_dlclose</CODE>, <CODE>_dlsym</CODE> or <CODE>_dlopen</CODE>
|
|
when linking, compile and link against the file
|
|
<TT>`mit/util/misc/dlsym.c'</TT> from the MIT version of X windows.
|
|
<P>
|
|
|
|
<LI>
|
|
The 128-bit long double format that the Sparc port supports currently
|
|
works by using the architecturally defined quad-word floating point
|
|
instructions. Since there is no hardware that supports these
|
|
instructions they must be emulated by the operating system. Long
|
|
doubles do not work in Sun OS versions 4.0.3 and earlier, because the
|
|
kernel emulator uses an obsolete and incompatible format. Long doubles
|
|
do not work in Sun OS version 4.1.1 due to a problem in a Sun library.
|
|
Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC
|
|
does not enable them by default. Long doubles appear to work in Sun OS
|
|
5.x (Solaris 2.x).
|
|
<P>
|
|
|
|
<LI>
|
|
On HP-UX version 9.01 on the HP PA, the HP compiler <CODE>cc</CODE> does not
|
|
compile GCC correctly. We do not yet know why. However, GCC
|
|
compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can
|
|
compile itself properly on 9.01.
|
|
<P>
|
|
|
|
<LI>
|
|
On the HP PA machine, ADB sometimes fails to work on functions compiled
|
|
with GCC. Specifically, it fails to work on functions that use
|
|
<CODE>alloca</CODE> or variable-size arrays. This is because GCC doesn't
|
|
generate HP-UX unwind descriptors for such functions. It may even be
|
|
impossible to generate them.
|
|
<P>
|
|
|
|
<LI>
|
|
Debugging (<SAMP>`-g'</SAMP>) is not supported on the HP PA machine, unless you use
|
|
the preliminary GNU tools (see section <A HREF="gcc_3.html#SEC46" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html#SEC46">3. Installing GNU CC</A>).
|
|
<P>
|
|
|
|
<LI>
|
|
Taking the address of a label may generate errors from the HP-UX
|
|
PA assembler. GAS for the PA does not have this problem.
|
|
<P>
|
|
|
|
<LI>
|
|
Using floating point parameters for indirect calls to static functions
|
|
will not work when using the HP assembler. There simply is no way for GCC
|
|
to specify what registers hold arguments for static functions when using
|
|
the HP assembler. GAS for the PA does not have this problem.
|
|
<P>
|
|
|
|
<LI>
|
|
In extremely rare cases involving some very large functions you may
|
|
receive errors from the HP linker complaining about an out of bounds
|
|
unconditional branch offset. This used to occur more often in previous
|
|
versions of GCC, but is now exceptionally rare. If you should run
|
|
into it, you can work around by making your function smaller.
|
|
<P>
|
|
|
|
<LI>
|
|
GCC compiled code sometimes emits warnings from the HP-UX assembler of
|
|
the form:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>(warning) Use of GR3 when
|
|
frame >= 8192 may cause conflict.
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
These warnings are harmless and can be safely ignored.
|
|
</P><P>
|
|
|
|
<LI>
|
|
The current version of the assembler (<TT>`/bin/as'</TT>) for the RS/6000
|
|
has certain problems that prevent the <SAMP>`-g'</SAMP> option in GCC from
|
|
working. Note that <TT>`Makefile.in'</TT> uses <SAMP>`-g'</SAMP> by default when
|
|
compiling <TT>`libgcc2.c'</TT>.
|
|
<P>
|
|
|
|
IBM has produced a fixed version of the assembler. The upgraded
|
|
assembler unfortunately was not included in any of the AIX 3.2 update
|
|
PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 should request
|
|
PTF U403044 from IBM and users of AIX 3.2 should request PTF U416277.
|
|
See the file <TT>`README.RS6000'</TT> for more details on these updates.
|
|
</P><P>
|
|
|
|
You can test for the presense of a fixed assembler by using the
|
|
command
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>as -u < /dev/null
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
If the command exits normally, the assembler fix already is installed.
|
|
If the assembler complains that "-u" is an unknown flag, you need to
|
|
order the fix.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On the IBM RS/6000, compiling code of the form
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>extern int foo;
|
|
|
|
<small>...</small> foo <small>...</small>
|
|
|
|
static int foo;
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
will cause the linker to report an undefined symbol <CODE>foo</CODE>.
|
|
Although this behavior differs from most other systems, it is not a
|
|
bug because redefining an <CODE>extern</CODE> variable as <CODE>static</CODE>
|
|
is undefined in ANSI C.
|
|
</P><P>
|
|
|
|
<LI>
|
|
AIX on the RS/6000 provides support (NLS) for environments outside of
|
|
the United States. Compilers and assemblers use NLS to support
|
|
locale-specific representations of various objects including
|
|
floating-point numbers ("." vs "," for separating decimal fractions).
|
|
There have been problems reported where the library linked with GCC does
|
|
not produce the same floating-point formats that the assembler accepts.
|
|
If you have this problem, set the LANG environment variable to "C" or
|
|
"En_US".
|
|
<P>
|
|
|
|
<LI>
|
|
Even if you specify <SAMP>`-fdollars-in-identifiers'</SAMP>,
|
|
you cannot successfully use <SAMP>`$'</SAMP> in identifiers on the RS/6000 due
|
|
to a restriction in the IBM assembler. GAS supports these
|
|
identifiers.
|
|
<P>
|
|
|
|
<LI>
|
|
On the RS/6000, XLC version 1.3.0.0 will miscompile <TT>`jump.c'</TT>. XLC
|
|
version 1.3.0.1 or later fixes this problem. You can obtain XLC-1.3.0.2
|
|
by requesting PTF 421749 from IBM.
|
|
<P>
|
|
|
|
<LI>
|
|
There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that
|
|
occurs when the <SAMP>`fldcr'</SAMP> instruction is used. GCC uses
|
|
<SAMP>`fldcr'</SAMP> on the 88100 to serialize volatile memory references. Use
|
|
the option <SAMP>`-mno-serialize-volatile'</SAMP> if your version of the
|
|
assembler has this bug.
|
|
<P>
|
|
|
|
<LI>
|
|
On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
|
|
messages from the linker. These warning messages complain of mismatched
|
|
psect attributes. You can ignore them. See section <A HREF="gcc_3.html#SEC58" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html#SEC58">3.6 Installing GNU CC on VMS</A>.
|
|
<P>
|
|
|
|
<LI>
|
|
On NewsOS version 3, if you include both of the files <TT>`stddef.h'</TT>
|
|
and <TT>`sys/types.h'</TT>, you get an error because there are two typedefs
|
|
of <CODE>size_t</CODE>. You should change <TT>`sys/types.h'</TT> by adding these
|
|
lines around the definition of <CODE>size_t</CODE>:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>#ifndef _SIZE_T
|
|
#define _SIZE_T
|
|
<VAR>actual typedef here</VAR>
|
|
#endif
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX362"></A>
|
|
<LI>
|
|
On the Alliant, the system's own convention for returning structures
|
|
and unions is unusual, and is not compatible with GCC no matter
|
|
what options are used.
|
|
<P>
|
|
|
|
<A NAME="IDX363"></A>
|
|
<A NAME="IDX364"></A>
|
|
<LI>
|
|
On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
|
|
convention for structure and union returning. Use the option
|
|
<SAMP>`-mhc-struct-return'</SAMP> to tell GCC to use a convention compatible
|
|
with it.
|
|
<P>
|
|
|
|
<A NAME="IDX365"></A>
|
|
<A NAME="IDX366"></A>
|
|
<LI>
|
|
On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved
|
|
by function calls. However, the C compiler uses conventions compatible
|
|
with BSD Unix: registers 2 through 5 may be clobbered by function calls.
|
|
<P>
|
|
|
|
GCC uses the same convention as the Ultrix C compiler. You can use
|
|
these options to produce code compatible with the Fortran compiler:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
On the WE32k, you may find that programs compiled with GCC do not
|
|
work with the standard shared C library. You may need to link with
|
|
the ordinary C compiler. If you do so, you must specify the following
|
|
options:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>-L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
The first specifies where to find the library <TT>`libgcc.a'</TT>
|
|
specified with the <SAMP>`-lgcc'</SAMP> option.
|
|
</P><P>
|
|
|
|
GCC does linking by invoking <CODE>ld</CODE>, just as <CODE>cc</CODE> does, and
|
|
there is no reason why it <EM>should</EM> matter which compilation program
|
|
you use to invoke <CODE>ld</CODE>. If someone tracks this problem down,
|
|
it can probably be fixed easily.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On the Alpha, you may get assembler errors about invalid syntax as a
|
|
result of floating point constants. This is due to a bug in the C
|
|
library functions <CODE>ecvt</CODE>, <CODE>fcvt</CODE> and <CODE>gcvt</CODE>. Given valid
|
|
floating point numbers, they sometimes print <SAMP>`NaN'</SAMP>.
|
|
<P>
|
|
|
|
<LI>
|
|
On Irix 4.0.5F (and perhaps in some other versions), an assembler bug
|
|
sometimes reorders instructions incorrectly when optimization is turned
|
|
on. If you think this may be happening to you, try using the GNU
|
|
assembler; GAS version 2.1 supports ECOFF on Irix.
|
|
<P>
|
|
|
|
Or use the <SAMP>`-noasmopt'</SAMP> option when you compile GCC with itself,
|
|
and then again when you compile your program. (This is a temporary
|
|
kludge to turn off assembler optimization on Irix.) If this proves to
|
|
be what you need, edit the assembler spec in the file <TT>`specs'</TT> so
|
|
that it unconditionally passes <SAMP>`-O0'</SAMP> to the assembler, and never
|
|
passes <SAMP>`-O2'</SAMP> or <SAMP>`-O3'</SAMP>.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="External Bugs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC123"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC122" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC122"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC124" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC124"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC124" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC124"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.5 Problems Compiling Certain Programs </H2>
|
|
<!--docid::SEC123::-->
|
|
<P>
|
|
|
|
Certain programs have problems compiling.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2
|
|
because of problems in DEC's versions of the X11 header files
|
|
<TT>`X11/Xlib.h'</TT> and <TT>`X11/Xutil.h'</TT>. People recommend adding
|
|
<SAMP>`-I/usr/include/mit'</SAMP> to use the MIT versions of the header files,
|
|
using the <SAMP>`-traditional'</SAMP> switch to turn off ANSI C, or fixing the
|
|
header files by adding this:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#ifdef __STDC__
|
|
#define NeedFunctionPrototypes 0
|
|
#endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
If you have trouble compiling Perl on a SunOS 4 system, it may be
|
|
because Perl specifies <SAMP>`-I/usr/ucbinclude'</SAMP>. This accesses the
|
|
unfixed header files. Perl specifies the options
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>-traditional -Dvolatile=__volatile__
|
|
-I/usr/include/sun -I/usr/ucbinclude
|
|
-fpcc-struct-return
|
|
</pre></td></tr></table></P><P>
|
|
|
|
most of which are unnecessary with GCC 2.4.5 and newer versions. You
|
|
can make a properly working Perl by setting <CODE>ccflags</CODE> to
|
|
<SAMP>`-fwritable-strings'</SAMP> (implied by the <SAMP>`-traditional'</SAMP> in the
|
|
original options) and <CODE>cppflags</CODE> to empty in <TT>`config.sh'</TT>, then
|
|
typing <SAMP>`./doSH; make depend; make'</SAMP>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On various 386 Unix systems derived from System V, including SCO, ISC,
|
|
and ESIX, you may get error messages about running out of virtual memory
|
|
while compiling certain programs.
|
|
<P>
|
|
|
|
You can prevent this problem by linking GCC with the GNU malloc
|
|
(which thus replaces the malloc that comes with the system). GNU malloc
|
|
is available as a separate package, and also in the file
|
|
<TT>`src/gmalloc.c'</TT> in the GNU Emacs 19 distribution.
|
|
</P><P>
|
|
|
|
If you have installed GNU malloc as a separate library package, use this
|
|
option when you relink GCC:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>MALLOC=/usr/local/lib/libgmalloc.a
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Alternatively, if you have compiled <TT>`gmalloc.c'</TT> from Emacs 19, copy
|
|
the object file to <TT>`gmalloc.o'</TT> and use this option when you relink
|
|
GCC:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>MALLOC=gmalloc.o
|
|
</pre></td></tr></table></UL>
|
|
<P>
|
|
|
|
<A NAME="Incompatibilities"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC124"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC123" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC123"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC125" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC125"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC125" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC125"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.6 Incompatibilities of GCC </H2>
|
|
<!--docid::SEC124::-->
|
|
<P>
|
|
|
|
There are several noteworthy incompatibilities between GNU C and most
|
|
existing (non-ANSI) versions of C. The <SAMP>`-traditional'</SAMP> option
|
|
eliminates many of these incompatibilities, <EM>but not all</EM>, by
|
|
telling GNU C to behave like the other C compilers.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<A NAME="IDX367"></A>
|
|
<A NAME="IDX368"></A>
|
|
<A NAME="IDX369"></A>
|
|
<LI>
|
|
GCC normally makes string constants read-only. If several
|
|
identical-looking string constants are used, GCC stores only one
|
|
copy of the string.
|
|
<P>
|
|
|
|
<A NAME="IDX370"></A>
|
|
One consequence is that you cannot call <CODE>mktemp</CODE> with a string
|
|
constant argument. The function <CODE>mktemp</CODE> always alters the
|
|
string its argument points to.
|
|
</P><P>
|
|
|
|
<A NAME="IDX371"></A>
|
|
<A NAME="IDX372"></A>
|
|
<A NAME="IDX373"></A>
|
|
Another consequence is that <CODE>sscanf</CODE> does not work on some systems
|
|
when passed a string constant as its format control string or input.
|
|
This is because <CODE>sscanf</CODE> incorrectly tries to write into the string
|
|
constant. Likewise <CODE>fscanf</CODE> and <CODE>scanf</CODE>.
|
|
</P><P>
|
|
|
|
The best solution to these problems is to change the program to use
|
|
<CODE>char</CODE>-array variables with initialization strings for these
|
|
purposes instead of string constants. But if this is not possible,
|
|
you can use the <SAMP>`-fwritable-strings'</SAMP> flag, which directs GCC
|
|
to handle string constants the same way most C compilers do.
|
|
<SAMP>`-traditional'</SAMP> also has this effect, among others.
|
|
</P><P>
|
|
|
|
<LI>
|
|
<CODE>-2147483648</CODE> is positive.
|
|
<P>
|
|
|
|
This is because 2147483648 cannot fit in the type <CODE>int</CODE>, so
|
|
(following the ANSI C rules) its data type is <CODE>unsigned long int</CODE>.
|
|
Negating this value yields 2147483648 again.
|
|
</P><P>
|
|
|
|
<LI>
|
|
GCC does not substitute macro arguments when they appear inside of
|
|
string constants. For example, the following macro in GCC
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define foo(a) "a"
|
|
</pre></td></tr></table></P><P>
|
|
|
|
will produce output <CODE>"a"</CODE> regardless of what the argument <VAR>a</VAR> is.
|
|
</P><P>
|
|
|
|
The <SAMP>`-traditional'</SAMP> option directs GCC to handle such cases
|
|
(among others) in the old-fashioned (non-ANSI) fashion.
|
|
</P><P>
|
|
|
|
<A NAME="IDX374"></A>
|
|
<A NAME="IDX375"></A>
|
|
<LI>
|
|
When you use <CODE>setjmp</CODE> and <CODE>longjmp</CODE>, the only automatic
|
|
variables guaranteed to remain valid are those declared
|
|
<CODE>volatile</CODE>. This is a consequence of automatic register
|
|
allocation. Consider this function:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>jmp_buf j;
|
|
|
|
foo ()
|
|
{
|
|
int a, b;
|
|
|
|
a = fun1 ();
|
|
if (setjmp (j))
|
|
return a;
|
|
|
|
a = fun2 ();
|
|
/* <CODE>longjmp (j)</CODE> may occur in <CODE>fun3</CODE>. */
|
|
return a + fun3 ();
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here <CODE>a</CODE> may or may not be restored to its first value when the
|
|
<CODE>longjmp</CODE> occurs. If <CODE>a</CODE> is allocated in a register, then
|
|
its first value is restored; otherwise, it keeps the last value stored
|
|
in it.
|
|
</P><P>
|
|
|
|
If you use the <SAMP>`-W'</SAMP> option with the <SAMP>`-O'</SAMP> option, you will
|
|
get a warning when GCC thinks such a problem might be possible.
|
|
</P><P>
|
|
|
|
The <SAMP>`-traditional'</SAMP> option directs GNU C to put variables in
|
|
the stack by default, rather than in registers, in functions that
|
|
call <CODE>setjmp</CODE>. This results in the behavior found in
|
|
traditional C compilers.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Programs that use preprocessing directives in the middle of macro
|
|
arguments do not work with GCC. For example, a program like this
|
|
will not work:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>foobar (
|
|
#define luser
|
|
hack)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
ANSI C does not permit such a construct. It would make sense to support
|
|
it when <SAMP>`-traditional'</SAMP> is used, but it is too much work to
|
|
implement.
|
|
</P><P>
|
|
|
|
<A NAME="IDX376"></A>
|
|
<A NAME="IDX377"></A>
|
|
<A NAME="IDX378"></A>
|
|
<LI>
|
|
Declarations of external variables and functions within a block apply
|
|
only to the block containing the declaration. In other words, they
|
|
have the same scope as any other declaration in the same place.
|
|
<P>
|
|
|
|
In some other C compilers, a <CODE>extern</CODE> declaration affects all the
|
|
rest of the file even if it happens within a block.
|
|
</P><P>
|
|
|
|
The <SAMP>`-traditional'</SAMP> option directs GNU C to treat all <CODE>extern</CODE>
|
|
declarations as global, like traditional compilers.
|
|
</P><P>
|
|
|
|
<LI>
|
|
In traditional C, you can combine <CODE>long</CODE>, etc., with a typedef name,
|
|
as shown here:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typedef int foo;
|
|
typedef long foo bar;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
In ANSI C, this is not allowed: <CODE>long</CODE> and other type modifiers
|
|
require an explicit <CODE>int</CODE>. Because this criterion is expressed
|
|
by Bison grammar rules rather than C code, the <SAMP>`-traditional'</SAMP>
|
|
flag cannot alter it.
|
|
</P><P>
|
|
|
|
<A NAME="IDX379"></A>
|
|
<LI>
|
|
PCC allows typedef names to be used as function parameters. The
|
|
difficulty described immediately above applies here too.
|
|
<P>
|
|
|
|
<A NAME="IDX380"></A>
|
|
<LI>
|
|
PCC allows whitespace in the middle of compound assignment operators
|
|
such as <SAMP>`+='</SAMP>. GCC, following the ANSI standard, does not
|
|
allow this. The difficulty described immediately above applies here
|
|
too.
|
|
<P>
|
|
|
|
<A NAME="IDX381"></A>
|
|
<A NAME="IDX382"></A>
|
|
<LI>
|
|
GCC complains about unterminated character constants inside of
|
|
preprocessing conditionals that fail. Some programs have English
|
|
comments enclosed in conditionals that are guaranteed to fail; if these
|
|
comments contain apostrophes, GCC will probably report an error. For
|
|
example, this code would produce an error:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#if 0
|
|
You can't expect this to work.
|
|
#endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The best solution to such a problem is to put the text into an actual
|
|
C comment delimited by <SAMP>`/*<small>...</small>*/'</SAMP>. However,
|
|
<SAMP>`-traditional'</SAMP> suppresses these error messages.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Many user programs contain the declaration <SAMP>`long time ();'</SAMP>. In the
|
|
past, the system header files on many systems did not actually declare
|
|
<CODE>time</CODE>, so it did not matter what type your program declared it to
|
|
return. But in systems with ANSI C headers, <CODE>time</CODE> is declared to
|
|
return <CODE>time_t</CODE>, and if that is not the same as <CODE>long</CODE>, then
|
|
<SAMP>`long time ();'</SAMP> is erroneous.
|
|
<P>
|
|
|
|
The solution is to change your program to use <CODE>time_t</CODE> as the return
|
|
type of <CODE>time</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX383"></A>
|
|
<LI>
|
|
When compiling functions that return <CODE>float</CODE>, PCC converts it to
|
|
a double. GCC actually returns a <CODE>float</CODE>. If you are concerned
|
|
with PCC compatibility, you should declare your functions to return
|
|
<CODE>double</CODE>; you might as well say what you mean.
|
|
<P>
|
|
|
|
<A NAME="IDX384"></A>
|
|
<A NAME="IDX385"></A>
|
|
<LI>
|
|
When compiling functions that return structures or unions, GCC
|
|
output code normally uses a method different from that used on most
|
|
versions of Unix. As a result, code compiled with GCC cannot call
|
|
a structure-returning function compiled with PCC, and vice versa.
|
|
<P>
|
|
|
|
The method used by GCC is as follows: a structure or union which is
|
|
1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union
|
|
with any other size is stored into an address supplied by the caller
|
|
(usually in a special, fixed register, but on some machines it is passed
|
|
on the stack). The machine-description macros <CODE>STRUCT_VALUE</CODE> and
|
|
<CODE>STRUCT_INCOMING_VALUE</CODE> tell GCC where to pass this address.
|
|
</P><P>
|
|
|
|
By contrast, PCC on most target machines returns structures and unions
|
|
of any size by copying the data into an area of static storage, and then
|
|
returning the address of that storage as if it were a pointer value.
|
|
The caller must copy the data from that memory area to the place where
|
|
the value is wanted. GCC does not use this method because it is
|
|
slower and nonreentrant.
|
|
</P><P>
|
|
|
|
On some newer machines, PCC uses a reentrant convention for all
|
|
structure and union returning. GCC on most of these machines uses a
|
|
compatible convention when returning structures and unions in memory,
|
|
but still returns small structures and unions in registers.
|
|
</P><P>
|
|
|
|
You can tell GCC to use a compatible convention for all structure and
|
|
union returning with the option <SAMP>`-fpcc-struct-return'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX386"></A>
|
|
<A NAME="IDX387"></A>
|
|
<LI>
|
|
GNU C complains about program fragments such as <SAMP>`0x74ae-0x4000'</SAMP>
|
|
which appear to be two hexadecimal constants separated by the minus
|
|
operator. Actually, this string is a single <EM>preprocessing token</EM>.
|
|
Each such token must correspond to one token in C. Since this does not,
|
|
GNU C prints an error message. Although it may appear obvious that what
|
|
is meant is an operator and two values, the ANSI C standard specifically
|
|
requires that this be treated as erroneous.
|
|
<P>
|
|
|
|
A <EM>preprocessing token</EM> is a <EM>preprocessing number</EM> if it
|
|
begins with a digit and is followed by letters, underscores, digits,
|
|
periods and <SAMP>`e+'</SAMP>, <SAMP>`e-'</SAMP>, <SAMP>`E+'</SAMP>, or <SAMP>`E-'</SAMP> character
|
|
sequences.
|
|
</P><P>
|
|
|
|
To make the above program fragment valid, place whitespace in front of
|
|
the minus sign. This whitespace will end the preprocessing number.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Fixed Headers"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC125"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC124" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC124"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC126" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC126"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC126" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC126"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.7 Fixed Header Files </H2>
|
|
<!--docid::SEC125::-->
|
|
<P>
|
|
|
|
GCC needs to install corrected versions of some system header files.
|
|
This is because most target systems have some header files that won't
|
|
work with GCC unless they are changed. Some have bugs, some are
|
|
incompatible with ANSI C, and some depend on special features of other
|
|
compilers.
|
|
</P><P>
|
|
|
|
Installing GCC automatically creates and installs the fixed header
|
|
files, by running a program called <CODE>fixincludes</CODE> (or for certain
|
|
targets an alternative such as <CODE>fixinc.svr4</CODE>). Normally, you
|
|
don't need to pay attention to this. But there are cases where it
|
|
doesn't do the right thing automatically.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
If you update the system's header files, such as by installing a new
|
|
system version, the fixed header files of GCC are not automatically
|
|
updated. The easiest way to update them is to reinstall GCC. (If
|
|
you want to be clever, look in the makefile and you can find a
|
|
shortcut.)
|
|
<P>
|
|
|
|
<LI>
|
|
On some systems, in particular SunOS 4, header file directories contain
|
|
machine-specific symbolic links in certain places. This makes it
|
|
possible to share most of the header files among hosts running the
|
|
same version of SunOS 4 on different machine models.
|
|
<P>
|
|
|
|
The programs that fix the header files do not understand this special
|
|
way of using symbolic links; therefore, the directory of fixed header
|
|
files is good only for the machine model used to build it.
|
|
</P><P>
|
|
|
|
In SunOS 4, only programs that look inside the kernel will notice the
|
|
difference between machine models. Therefore, for most purposes, you
|
|
need not be concerned about this.
|
|
</P><P>
|
|
|
|
It is possible to make separate sets of fixed header files for the
|
|
different machine models, and arrange a structure of symbolic links so
|
|
as to use the proper set, but you'll have to do this by hand.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On Lynxos, GCC by default does not fix the header files. This is
|
|
because bugs in the shell cause the <CODE>fixincludes</CODE> script to fail.
|
|
<P>
|
|
|
|
This means you will encounter problems due to bugs in the system header
|
|
files. It may be no comfort that they aren't GCC's fault, but it
|
|
does mean that there's nothing for us to do about them.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Standard Libraries"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC126"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC125" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC125"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC127" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC127"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC127" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC127"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.8 Standard Libraries </H2>
|
|
<!--docid::SEC126::-->
|
|
<P>
|
|
|
|
GCC by itself attempts to be what the ISO/ANSI C standard calls a
|
|
<EM>conforming freestanding implementation</EM>. This means all ANSI
|
|
C language features are available, as well as the contents of
|
|
<TT>`float.h'</TT>, <TT>`limits.h'</TT>, <TT>`stdarg.h'</TT>, and
|
|
<TT>`stddef.h'</TT>. The rest of the C library is supplied by the
|
|
vendor of the operating system. If that C library doesn't conform to
|
|
the C standards, then your programs might get warnings (especially when
|
|
using <SAMP>`-Wall'</SAMP>) that you don't expect.
|
|
</P><P>
|
|
|
|
For example, the <CODE>sprintf</CODE> function on SunOS 4.1.3 returns
|
|
<CODE>char *</CODE> while the C standard says that <CODE>sprintf</CODE> returns an
|
|
<CODE>int</CODE>. The <CODE>fixincludes</CODE> program could make the prototype for
|
|
this function match the Standard, but that would be wrong, since the
|
|
function will still return <CODE>char *</CODE>.
|
|
</P><P>
|
|
|
|
If you need a Standard compliant library, then you need to find one, as
|
|
GCC does not provide one. The GNU C library (called <CODE>glibc</CODE>)
|
|
has been ported to a number of operating systems, and provides ANSI/ISO,
|
|
POSIX, BSD and SystemV compatibility. You could also ask your operating
|
|
system vendor if newer libraries are available.
|
|
</P><P>
|
|
|
|
<A NAME="Disappointments"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC127"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC126" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC126"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC128" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC128"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.9 Disappointments and Misunderstandings </H2>
|
|
<!--docid::SEC127::-->
|
|
<P>
|
|
|
|
These problems are perhaps regrettable, but we don't know any practical
|
|
way around them.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Certain local variables aren't recognized by debuggers when you compile
|
|
with optimization.
|
|
<P>
|
|
|
|
This occurs because sometimes GCC optimizes the variable out of
|
|
existence. There is no way to tell the debugger how to compute the
|
|
value such a variable "would have had", and it is not clear that would
|
|
be desirable anyway. So GCC simply does not mention the eliminated
|
|
variable when it writes debugging information.
|
|
</P><P>
|
|
|
|
You have to expect a certain amount of disagreement between the
|
|
executable and your source code, when you use optimization.
|
|
</P><P>
|
|
|
|
<A NAME="IDX388"></A>
|
|
<A NAME="IDX389"></A>
|
|
<LI>
|
|
Users often think it is a bug when GCC reports an error for code
|
|
like this:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int foo (struct mumble *);
|
|
|
|
struct mumble { <small>...</small> };
|
|
|
|
int foo (struct mumble *x)
|
|
{ <small>...</small> }
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This code really is erroneous, because the scope of <CODE>struct
|
|
mumble</CODE> in the prototype is limited to the argument list containing it.
|
|
It does not refer to the <CODE>struct mumble</CODE> defined with file scope
|
|
immediately below--they are two unrelated types with similar names in
|
|
different scopes.
|
|
</P><P>
|
|
|
|
But in the definition of <CODE>foo</CODE>, the file-scope type is used
|
|
because that is available to be inherited. Thus, the definition and
|
|
the prototype do not match, and you get an error.
|
|
</P><P>
|
|
|
|
This behavior may seem silly, but it's what the ANSI standard specifies.
|
|
It is easy enough for you to make your code work by moving the
|
|
definition of <CODE>struct mumble</CODE> above the prototype. It's not worth
|
|
being incompatible with ANSI C just to avoid an error for the example
|
|
shown above.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Accesses to bitfields even in volatile objects works by accessing larger
|
|
objects, such as a byte or a word. You cannot rely on what size of
|
|
object is accessed in order to read or write the bitfield; it may even
|
|
vary for a given bitfield according to the precise usage.
|
|
<P>
|
|
|
|
If you care about controlling the amount of memory that is accessed, use
|
|
volatile but do not use bitfields.
|
|
</P><P>
|
|
|
|
<LI>
|
|
GCC comes with shell scripts to fix certain known problems in system
|
|
header files. They install corrected copies of various header files in
|
|
a special directory where only GCC will normally look for them. The
|
|
scripts adapt to various systems by searching all the system header
|
|
files for the problem cases that we know about.
|
|
<P>
|
|
|
|
If new system header files are installed, nothing automatically arranges
|
|
to update the corrected header files. You will have to reinstall GCC
|
|
to fix the new header files. More specifically, go to the build
|
|
directory and delete the files <TT>`stmp-fixinc'</TT> and
|
|
<TT>`stmp-headers'</TT>, and the subdirectory <CODE>include</CODE>; then do
|
|
<SAMP>`make install'</SAMP> again.
|
|
</P><P>
|
|
|
|
<LI>
|
|
<A NAME="IDX390"></A>
|
|
On 68000 and x86 systems, for instance, you can get paradoxical results
|
|
if you test the precise values of floating point numbers. For example,
|
|
you can find that a floating point value which is not a NaN is not equal
|
|
to itself. This results from the fact that the floating point registers
|
|
hold a few more bits of precision than fit in a <CODE>double</CODE> in memory.
|
|
Compiled code moves values between memory and floating point registers
|
|
at its convenience, and moving them into memory truncates them.
|
|
<P>
|
|
|
|
You can partially avoid this problem by using the <SAMP>`-ffloat-store'</SAMP>
|
|
option (see section <A HREF="gcc_2.html#SEC10" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC10">2.8 Options That Control Optimization</A>).
|
|
</P><P>
|
|
|
|
<LI>
|
|
On the MIPS, variable argument functions using <TT>`varargs.h'</TT>
|
|
cannot have a floating point value for the first argument. The
|
|
reason for this is that in the absence of a prototype in scope,
|
|
if the first argument is a floating point, it is passed in a
|
|
floating point register, rather than an integer register.
|
|
<P>
|
|
|
|
If the code is rewritten to use the ANSI standard <TT>`stdarg.h'</TT>
|
|
method of variable arguments, and the prototype is in scope at
|
|
the time of the call, everything will work fine.
|
|
</P><P>
|
|
|
|
<LI>
|
|
On the H8/300 and H8/300H, variable argument functions must be
|
|
implemented using the ANSI standard <TT>`stdarg.h'</TT> method of
|
|
variable arguments. Furthermore, calls to functions using <TT>`stdarg.h'</TT>
|
|
variable arguments must have a prototype for the called function
|
|
in scope at the time of the call.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="C++ Misunderstandings"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC128"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC127" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC127"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC129" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC129"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.10 Common Misunderstandings with GNU C++ </H2>
|
|
<!--docid::SEC128::-->
|
|
<P>
|
|
|
|
<A NAME="IDX391"></A>
|
|
<A NAME="IDX392"></A>
|
|
<A NAME="IDX393"></A>
|
|
C++ is a complex language and an evolving one, and its standard
|
|
definition (the ISO C++ standard) was only recently completed. As a
|
|
result, your C++ compiler may occasionally surprise you, even when its
|
|
behavior is correct. This section discusses some areas that frequently
|
|
give rise to questions of this sort.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC129" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC129">7.10.1 Declare <EM>and</EM> Define Static Members</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Static member declarations are not definitions</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC130" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC130">7.10.2 Temporaries May Vanish Before You Expect</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Temporaries may vanish before you expect</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC131" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC131">7.10.3 Implicit Copy-Assignment for Virtual Bases</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Copy Assignment operators copy virtual bases twice</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Static Definitions"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC129"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC128" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC128"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC130" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC130"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC128" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC128"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 7.10.1 Declare <EM>and</EM> Define Static Members </H3>
|
|
<!--docid::SEC129::-->
|
|
<P>
|
|
|
|
<A NAME="IDX394"></A>
|
|
<A NAME="IDX395"></A>
|
|
<A NAME="IDX396"></A>
|
|
<A NAME="IDX397"></A>
|
|
When a class has static data members, it is not enough to <EM>declare</EM>
|
|
the static member; you must also <EM>define</EM> it. For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>class Foo
|
|
{
|
|
<small>...</small>
|
|
void method();
|
|
static int bar;
|
|
};
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This declaration only establishes that the class <CODE>Foo</CODE> has an
|
|
<CODE>int</CODE> named <CODE>Foo::bar</CODE>, and a member function named
|
|
<CODE>Foo::method</CODE>. But you still need to define <EM>both</EM>
|
|
<CODE>method</CODE> and <CODE>bar</CODE> elsewhere. According to the draft ANSI
|
|
standard, you must supply an initializer in one (and only one) source
|
|
file, such as:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int Foo::bar = 0;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Other C++ compilers may not correctly implement the standard behavior.
|
|
As a result, when you switch to <CODE>g++</CODE> from one of these compilers,
|
|
you may discover that a program that appeared to work correctly in fact
|
|
does not conform to the standard: <CODE>g++</CODE> reports as undefined
|
|
symbols any static data members that lack definitions.
|
|
</P><P>
|
|
|
|
<A NAME="Temporaries"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC130"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC129" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC129"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC131" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC131"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC131" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC131"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC128" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC128"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 7.10.2 Temporaries May Vanish Before You Expect </H3>
|
|
<!--docid::SEC130::-->
|
|
<P>
|
|
|
|
<A NAME="IDX398"></A>
|
|
<A NAME="IDX399"></A>
|
|
It is dangerous to use pointers or references to <EM>portions</EM> of a
|
|
temporary object. The compiler may very well delete the object before
|
|
you expect it to, leaving a pointer to garbage. The most common place
|
|
where this problem crops up is in classes like string classes,
|
|
especially ones that define a conversion function to type <CODE>char *</CODE>
|
|
or <CODE>const char *</CODE> -- which is one reason why the standard
|
|
<CODE>string</CODE> class requires you to call the <CODE>c_str</CODE> member
|
|
function. However, any class that returns a pointer to some internal
|
|
structure is potentially subject to this problem.
|
|
</P><P>
|
|
|
|
For example, a program may use a function <CODE>strfunc</CODE> that returns
|
|
<CODE>string</CODE> objects, and another function <CODE>charfunc</CODE> that
|
|
operates on pointers to <CODE>char</CODE>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>string strfunc ();
|
|
void charfunc (const char *);
|
|
|
|
void
|
|
f ()
|
|
{
|
|
const char *p = strfunc().c_str();
|
|
...
|
|
charfunc (p);
|
|
...
|
|
charfunc (p);
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
In this situation, it may seem reasonable to save a pointer to the C
|
|
string returned by the <CODE>c_str</CODE> member function and use that rather
|
|
than call <CODE>c_str</CODE> repeatedly. However, the temporary string
|
|
created by the call to <CODE>strfunc</CODE> is destroyed after <CODE>p</CODE> is
|
|
initialized, at which point <CODE>p</CODE> is left pointing to freed memory.
|
|
</P><P>
|
|
|
|
Code like this may run successfully under some other compilers,
|
|
particularly obsolete cfront-based compilers that delete temporaries
|
|
along with normal local variables. However, the GNU C++ behavior is
|
|
standard-conforming, so if your program depends on late destruction of
|
|
temporaries it is not portable.
|
|
</P><P>
|
|
|
|
The safe way to write such code is to give the temporary a name, which
|
|
forces it to remain until the end of the scope of the name. For
|
|
example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>string& tmp = strfunc ();
|
|
charfunc (tmp.c_str ());
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Copy Assignment"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC131"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC130" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC130"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC128" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC128"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 7.10.3 Implicit Copy-Assignment for Virtual Bases </H3>
|
|
<!--docid::SEC131::-->
|
|
<P>
|
|
|
|
When a base class is virtual, only one subobject of the base class
|
|
belongs to each full object. Also, the constructors and destructors are
|
|
invoked only once, and called from the most-derived class. However, such
|
|
objects behave unspecified when being assigned. For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct Base{
|
|
char *name;
|
|
Base(char *n) : name(strdup(n)){}
|
|
Base& operator= (const Base& other){
|
|
free (name);
|
|
name = strdup (other.name);
|
|
}
|
|
};
|
|
|
|
struct A:virtual Base{
|
|
int val;
|
|
A():Base("A"){}
|
|
};
|
|
|
|
struct B:virtual Base{
|
|
int bval;
|
|
B():Base("B"){}
|
|
};
|
|
|
|
struct Derived:public A, public B{
|
|
Derived():Base("Derived"){}
|
|
};
|
|
|
|
void func(Derived &d1, Derived &d2)
|
|
{
|
|
d1 = d2;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The C++ standard specifies that <SAMP>`Base::Base'</SAMP> is only called once
|
|
when constructing or copy-constructing a Derived object. It is
|
|
unspecified whether <SAMP>`Base::operator='</SAMP> is called more than once when
|
|
the implicit copy-assignment for Derived objects is invoked (as it is
|
|
inside <SAMP>`func'</SAMP> in the example).
|
|
</P><P>
|
|
|
|
g++ implements the "intuitive" algorithm for copy-assignment: assign all
|
|
direct bases, then assign all members. In that algorithm, the virtual
|
|
base subobject can be encountered many times. In the example, copying
|
|
proceeds in the following order: <SAMP>`val'</SAMP>, <SAMP>`name'</SAMP> (via
|
|
<CODE>strdup</CODE>), <SAMP>`bval'</SAMP>, and <SAMP>`name'</SAMP> again.
|
|
</P><P>
|
|
|
|
If application code relies on copy-assignment, a user-defined
|
|
copy-assignment operator removes any uncertainties. With such an
|
|
operator, the application can define whether and how the virtual base
|
|
subobject is assigned.
|
|
</P><P>
|
|
|
|
<A NAME="Protoize Caveats"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC132"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC131" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC131"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC133" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC133"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.11 Caveats of using <CODE>protoize</CODE> </H2>
|
|
<!--docid::SEC132::-->
|
|
<P>
|
|
|
|
The conversion programs <CODE>protoize</CODE> and <CODE>unprotoize</CODE> can
|
|
sometimes change a source file in a way that won't work unless you
|
|
rearrange it.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
<CODE>protoize</CODE> can insert references to a type name or type tag before
|
|
the definition, or in a file where they are not defined.
|
|
<P>
|
|
|
|
If this happens, compiler error messages should show you where the new
|
|
references are, so fixing the file by hand is straightforward.
|
|
</P><P>
|
|
|
|
<LI>
|
|
There are some C constructs which <CODE>protoize</CODE> cannot figure out.
|
|
For example, it can't determine argument types for declaring a
|
|
pointer-to-function variable; this you must do by hand. <CODE>protoize</CODE>
|
|
inserts a comment containing <SAMP>`???'</SAMP> each time it finds such a
|
|
variable; so you can find all such variables by searching for this
|
|
string. ANSI C does not require declaring the argument types of
|
|
pointer-to-function types.
|
|
<P>
|
|
|
|
<LI>
|
|
Using <CODE>unprotoize</CODE> can easily introduce bugs. If the program
|
|
relied on prototypes to bring about conversion of arguments, these
|
|
conversions will not take place in the program without prototypes.
|
|
One case in which you can be sure <CODE>unprotoize</CODE> is safe is when
|
|
you are removing prototypes that were made with <CODE>protoize</CODE>; if
|
|
the program worked before without any prototypes, it will work again
|
|
without them.
|
|
<P>
|
|
|
|
You can find all the places where this problem might occur by compiling
|
|
the program with the <SAMP>`-Wconversion'</SAMP> option. It prints a warning
|
|
whenever an argument is converted.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Both conversion programs can be confused if there are macro calls in and
|
|
around the text to be converted. In other words, the standard syntax
|
|
for a declaration or definition must not result from expanding a macro.
|
|
This problem is inherent in the design of C and cannot be fixed. If
|
|
only a few functions have confusing macro calls, you can easily convert
|
|
them manually.
|
|
<P>
|
|
|
|
<LI>
|
|
<CODE>protoize</CODE> cannot get the argument types for a function whose
|
|
definition was not actually compiled due to preprocessing conditionals.
|
|
When this happens, <CODE>protoize</CODE> changes nothing in regard to such
|
|
a function. <CODE>protoize</CODE> tries to detect such instances and warn
|
|
about them.
|
|
<P>
|
|
|
|
You can generally work around this problem by using <CODE>protoize</CODE> step
|
|
by step, each time specifying a different set of <SAMP>`-D'</SAMP> options for
|
|
compilation, until all of the functions have been converted. There is
|
|
no automatic way to verify that you have got them all, however.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Confusion may result if there is an occasion to convert a function
|
|
declaration or definition in a region of source code where there is more
|
|
than one formal parameter list present. Thus, attempts to convert code
|
|
containing multiple (conditionally compiled) versions of a single
|
|
function header (in the same vicinity) may not produce the desired (or
|
|
expected) results.
|
|
<P>
|
|
|
|
If you plan on converting source files which contain such code, it is
|
|
recommended that you first make sure that each conditionally compiled
|
|
region of source code which contains an alternative function header also
|
|
contains at least one additional follower token (past the final right
|
|
parenthesis of the function header). This should circumvent the
|
|
problem.
|
|
</P><P>
|
|
|
|
<LI>
|
|
<CODE>unprotoize</CODE> can become confused when trying to convert a function
|
|
definition or declaration which contains a declaration for a
|
|
pointer-to-function formal argument which has the same name as the
|
|
function being defined or declared. We recommand you avoid such choices
|
|
of formal parameter names.
|
|
<P>
|
|
|
|
<LI>
|
|
You might also want to correct some of the indentation by hand and break
|
|
long lines. (The conversion programs don't write lines longer than
|
|
eighty characters in any case.)
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Non-bugs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC133"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC132" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC132"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC134" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC134"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.12 Certain Changes We Don't Want to Make </H2>
|
|
<!--docid::SEC133::-->
|
|
<P>
|
|
|
|
This section lists changes that people frequently request, but which
|
|
we do not make because we think GCC is better without them.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Checking the number and type of arguments to a function which has an
|
|
old-fashioned definition and no prototype.
|
|
<P>
|
|
|
|
Such a feature would work only occasionally--only for calls that appear
|
|
in the same file as the called function, following the definition. The
|
|
only way to check all calls reliably is to add a prototype for the
|
|
function. But adding a prototype eliminates the motivation for this
|
|
feature. So the feature is not worthwhile.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Warning about using an expression whose type is signed as a shift count.
|
|
<P>
|
|
|
|
Shift count operands are probably signed more often than unsigned.
|
|
Warning about this would cause far more annoyance than good.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Warning about assigning a signed value to an unsigned variable.
|
|
<P>
|
|
|
|
Such assignments must be very common; warning about them would cause
|
|
more annoyance than good.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Warning about unreachable code.
|
|
<P>
|
|
|
|
It's very common to have unreachable code in machine-generated
|
|
programs. For example, this happens normally in some files of GNU C
|
|
itself.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Warning when a non-void function value is ignored.
|
|
<P>
|
|
|
|
Coming as I do from a Lisp background, I balk at the idea that there is
|
|
something dangerous about discarding a value. There are functions that
|
|
return values which some callers may find useful; it makes no sense to
|
|
clutter the program with a cast to <CODE>void</CODE> whenever the value isn't
|
|
useful.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Assuming (for optimization) that the address of an external symbol is
|
|
never zero.
|
|
<P>
|
|
|
|
This assumption is false on certain systems when <SAMP>`#pragma weak'</SAMP> is
|
|
used.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Making <SAMP>`-fshort-enums'</SAMP> the default.
|
|
<P>
|
|
|
|
This would cause storage layout to be incompatible with most other C
|
|
compilers. And it doesn't seem very important, given that you can get
|
|
the same result in other ways. The case where it matters most is when
|
|
the enumeration-valued object is inside a structure, and in that case
|
|
you can specify a field width explicitly.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Making bitfields unsigned by default on particular machines where "the
|
|
ABI standard" says to do so.
|
|
<P>
|
|
|
|
The ANSI C standard leaves it up to the implementation whether a bitfield
|
|
declared plain <CODE>int</CODE> is signed or not. This in effect creates two
|
|
alternative dialects of C.
|
|
</P><P>
|
|
|
|
The GNU C compiler supports both dialects; you can specify the signed
|
|
dialect with <SAMP>`-fsigned-bitfields'</SAMP> and the unsigned dialect with
|
|
<SAMP>`-funsigned-bitfields'</SAMP>. However, this leaves open the question of
|
|
which dialect to use by default.
|
|
</P><P>
|
|
|
|
Currently, the preferred dialect makes plain bitfields signed, because
|
|
this is simplest. Since <CODE>int</CODE> is the same as <CODE>signed int</CODE> in
|
|
every other context, it is cleanest for them to be the same in bitfields
|
|
as well.
|
|
</P><P>
|
|
|
|
Some computer manufacturers have published Application Binary Interface
|
|
standards which specify that plain bitfields should be unsigned. It is
|
|
a mistake, however, to say anything about this issue in an ABI. This is
|
|
because the handling of plain bitfields distinguishes two dialects of C.
|
|
Both dialects are meaningful on every type of machine. Whether a
|
|
particular object file was compiled using signed bitfields or unsigned
|
|
is of no concern to other object files, even if they access the same
|
|
bitfields in the same data structures.
|
|
</P><P>
|
|
|
|
A given program is written in one or the other of these two dialects.
|
|
The program stands a chance to work on most any machine if it is
|
|
compiled with the proper dialect. It is unlikely to work at all if
|
|
compiled with the wrong dialect.
|
|
</P><P>
|
|
|
|
Many users appreciate the GNU C compiler because it provides an
|
|
environment that is uniform across machines. These users would be
|
|
inconvenienced if the compiler treated plain bitfields differently on
|
|
certain machines.
|
|
</P><P>
|
|
|
|
Occasionally users write programs intended only for a particular machine
|
|
type. On these occasions, the users would benefit if the GNU C compiler
|
|
were to support by default the same dialect as the other compilers on
|
|
that machine. But such applications are rare. And users writing a
|
|
program to run on more than one type of machine cannot possibly benefit
|
|
from this kind of compatibility.
|
|
</P><P>
|
|
|
|
This is why GCC does and will treat plain bitfields in the same
|
|
fashion on all types of machines (by default).
|
|
</P><P>
|
|
|
|
There are some arguments for making bitfields unsigned by default on all
|
|
machines. If, for example, this becomes a universal de facto standard,
|
|
it would make sense for GCC to go along with it. This is something
|
|
to be considered in the future.
|
|
</P><P>
|
|
|
|
(Of course, users strongly concerned about portability should indicate
|
|
explicitly in each bitfield whether it is signed or not. In this way,
|
|
they write programs which have the same meaning in both C dialects.)
|
|
</P><P>
|
|
|
|
<LI>
|
|
Undefining <CODE>__STDC__</CODE> when <SAMP>`-ansi'</SAMP> is not used.
|
|
<P>
|
|
|
|
Currently, GCC defines <CODE>__STDC__</CODE> as long as you don't use
|
|
<SAMP>`-traditional'</SAMP>. This provides good results in practice.
|
|
</P><P>
|
|
|
|
Programmers normally use conditionals on <CODE>__STDC__</CODE> to ask whether
|
|
it is safe to use certain features of ANSI C, such as function
|
|
prototypes or ANSI token concatenation. Since plain <SAMP>`gcc'</SAMP> supports
|
|
all the features of ANSI C, the correct answer to these questions is
|
|
"yes".
|
|
</P><P>
|
|
|
|
Some users try to use <CODE>__STDC__</CODE> to check for the availability of
|
|
certain library facilities. This is actually incorrect usage in an ANSI
|
|
C program, because the ANSI C standard says that a conforming
|
|
freestanding implementation should define <CODE>__STDC__</CODE> even though it
|
|
does not have the library facilities. <SAMP>`gcc -ansi -pedantic'</SAMP> is a
|
|
conforming freestanding implementation, and it is therefore required to
|
|
define <CODE>__STDC__</CODE>, even though it does not come with an ANSI C
|
|
library.
|
|
</P><P>
|
|
|
|
Sometimes people say that defining <CODE>__STDC__</CODE> in a compiler that
|
|
does not completely conform to the ANSI C standard somehow violates the
|
|
standard. This is illogical. The standard is a standard for compilers
|
|
that claim to support ANSI C, such as <SAMP>`gcc -ansi'</SAMP>---not for other
|
|
compilers such as plain <SAMP>`gcc'</SAMP>. Whatever the ANSI C standard says
|
|
is relevant to the design of plain <SAMP>`gcc'</SAMP> without <SAMP>`-ansi'</SAMP> only
|
|
for pragmatic reasons, not as a requirement.
|
|
</P><P>
|
|
|
|
GCC normally defines <CODE>__STDC__</CODE> to be 1, and in addition
|
|
defines <CODE>__STRICT_ANSI__</CODE> if you specify the <SAMP>`-ansi'</SAMP> option.
|
|
On some hosts, system include files use a different convention, where
|
|
<CODE>__STDC__</CODE> is normally 0, but is 1 if the user specifies strict
|
|
conformance to the C Standard. GCC follows the host convention when
|
|
processing system include files, but when processing user files it follows
|
|
the usual GNU C convention.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Undefining <CODE>__STDC__</CODE> in C++.
|
|
<P>
|
|
|
|
Programs written to compile with C++-to-C translators get the
|
|
value of <CODE>__STDC__</CODE> that goes with the C compiler that is
|
|
subsequently used. These programs must test <CODE>__STDC__</CODE>
|
|
to determine what kind of C preprocessor that compiler uses:
|
|
whether they should concatenate tokens in the ANSI C fashion
|
|
or in the traditional fashion.
|
|
</P><P>
|
|
|
|
These programs work properly with GNU C++ if <CODE>__STDC__</CODE> is defined.
|
|
They would not work otherwise.
|
|
</P><P>
|
|
|
|
In addition, many header files are written to provide prototypes in ANSI
|
|
C but not in traditional C. Many of these header files can work without
|
|
change in C++ provided <CODE>__STDC__</CODE> is defined. If <CODE>__STDC__</CODE>
|
|
is not defined, they will all fail, and will all need to be changed to
|
|
test explicitly for C++ as well.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Deleting "empty" loops.
|
|
<P>
|
|
|
|
Historically, GCC has not deleted "empty" loops under the
|
|
assumption that the most likely reason you would put one in a program is
|
|
to have a delay, so deleting them will not make real programs run any
|
|
faster.
|
|
</P><P>
|
|
|
|
However, the rationale here is that optimization of a nonempty loop
|
|
cannot produce an empty one, which holds for C but is not always the
|
|
case for C++.
|
|
</P><P>
|
|
|
|
Moreover, with <SAMP>`-funroll-loops'</SAMP> small "empty" loops are already
|
|
removed, so the current behavior is both sub-optimal and inconsistent
|
|
and will change in the future.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Making side effects happen in the same order as in some other compiler.
|
|
<P>
|
|
|
|
<A NAME="IDX400"></A>
|
|
<A NAME="IDX401"></A>
|
|
It is never safe to depend on the order of evaluation of side effects.
|
|
For example, a function call like this may very well behave differently
|
|
from one compiler to another:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>void func (int, int);
|
|
|
|
int i = 2;
|
|
func (i++, i++);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
There is no guarantee (in either the C or the C++ standard language
|
|
definitions) that the increments will be evaluated in any particular
|
|
order. Either increment might happen first. <CODE>func</CODE> might get the
|
|
arguments <SAMP>`2, 3'</SAMP>, or it might get <SAMP>`3, 2'</SAMP>, or even <SAMP>`2, 2'</SAMP>.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Not allowing structures with volatile fields in registers.
|
|
<P>
|
|
|
|
Strictly speaking, there is no prohibition in the ANSI C standard
|
|
against allowing structures with volatile fields in registers, but
|
|
it does not seem to make any sense and is probably not what you wanted
|
|
to do. So the compiler will give an error message in this case.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Warnings and Errors"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC134"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC133" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC133"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 7.13 Warning Messages and Error Messages </H2>
|
|
<!--docid::SEC134::-->
|
|
<P>
|
|
|
|
<A NAME="IDX402"></A>
|
|
<A NAME="IDX403"></A>
|
|
<A NAME="IDX404"></A>
|
|
The GNU compiler can produce two kinds of diagnostics: errors and
|
|
warnings. Each kind has a different purpose:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
<EM>Errors</EM> report problems that make it impossible to compile your
|
|
program. GCC reports errors with the source file name and line
|
|
number where the problem is apparent.
|
|
<P>
|
|
|
|
<LI>
|
|
<EM>Warnings</EM> report other unusual conditions in your code that
|
|
<EM>may</EM> indicate a problem, although compilation can (and does)
|
|
proceed. Warning messages also report the source file name and line
|
|
number, but include the text <SAMP>`warning:'</SAMP> to distinguish them
|
|
from error messages.
|
|
</UL>
|
|
<P>
|
|
|
|
Warnings may indicate danger points where you should check to make sure
|
|
that your program really does what you intend; or the use of obsolete
|
|
features; or the use of nonstandard features of GNU C or C++. Many
|
|
warnings are issued only if you ask for them, with one of the <SAMP>`-W'</SAMP>
|
|
options (for instance, <SAMP>`-Wall'</SAMP> requests a variety of useful
|
|
warnings).
|
|
</P><P>
|
|
|
|
GCC always tries to compile your program if possible; it never
|
|
gratuitously rejects a program whose meaning is clear merely because
|
|
(for instance) it fails to conform to a standard. In some cases,
|
|
however, the C and C++ standards specify that certain extensions are
|
|
forbidden, and a diagnostic <EM>must</EM> be issued by a conforming
|
|
compiler. The <SAMP>`-pedantic'</SAMP> option tells GCC to issue warnings in
|
|
such cases; <SAMP>`-pedantic-errors'</SAMP> says to make them errors instead.
|
|
This does not mean that <EM>all</EM> non-ANSI constructs get warnings
|
|
or errors.
|
|
</P><P>
|
|
|
|
See section <A HREF="gcc_2.html#SEC8" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC8">Options to Request or Suppress Warnings</A>, for
|
|
more detail on these and related command-line options.
|
|
</P><P>
|
|
|
|
<A NAME="Bugs"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC120" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC120"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
This document was generated
|
|
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
|
|
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|