trouble.texi revision 90075
190075Sobrien@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 290075Sobrien@c 1999, 2000, 2001 Free Software Foundation, Inc. 390075Sobrien@c This is part of the GCC manual. 490075Sobrien@c For copying conditions, see the file gcc.texi. 590075Sobrien 690075Sobrien@node Trouble 790075Sobrien@chapter Known Causes of Trouble with GCC 890075Sobrien@cindex bugs, known 990075Sobrien@cindex installation trouble 1090075Sobrien@cindex known causes of trouble 1190075Sobrien 1290075SobrienThis section describes known problems that affect users of GCC@. Most 1390075Sobrienof these are not GCC bugs per se---if they were, we would fix them. 1490075SobrienBut the result for a user may be like the result of a bug. 1590075Sobrien 1690075SobrienSome of these problems are due to bugs in other software, some are 1790075Sobrienmissing features that are too much work to add, and some are places 1890075Sobrienwhere people's opinions differ as to what is best. 1990075Sobrien 2090075Sobrien@menu 2190075Sobrien* Actual Bugs:: Bugs we will fix later. 2290075Sobrien* Cross-Compiler Problems:: Common problems of cross compiling with GCC. 2390075Sobrien* Interoperation:: Problems using GCC with other compilers, 2490075Sobrien and with certain linkers, assemblers and debuggers. 2590075Sobrien* External Bugs:: Problems compiling certain programs. 2690075Sobrien* Incompatibilities:: GCC is incompatible with traditional C. 2790075Sobrien* Fixed Headers:: GCC uses corrected versions of system header files. 2890075Sobrien This is necessary, but doesn't always work smoothly. 2990075Sobrien* Standard Libraries:: GCC uses the system C library, which might not be 3090075Sobrien compliant with the ISO C standard. 3190075Sobrien* Disappointments:: Regrettable things we can't change, but not quite bugs. 3290075Sobrien* C++ Misunderstandings:: Common misunderstandings with GNU C++. 3390075Sobrien* Protoize Caveats:: Things to watch out for when using @code{protoize}. 3490075Sobrien* Non-bugs:: Things we think are right, but some others disagree. 3590075Sobrien* Warnings and Errors:: Which problems in your code get warnings, 3690075Sobrien and which get errors. 3790075Sobrien@end menu 3890075Sobrien 3990075Sobrien@node Actual Bugs 4090075Sobrien@section Actual Bugs We Haven't Fixed Yet 4190075Sobrien 4290075Sobrien@itemize @bullet 4390075Sobrien@item 4490075SobrienThe @code{fixincludes} script interacts badly with automounters; if the 4590075Sobriendirectory of system header files is automounted, it tends to be 4690075Sobrienunmounted while @code{fixincludes} is running. This would seem to be a 4790075Sobrienbug in the automounter. We don't know any good way to work around it. 4890075Sobrien 4990075Sobrien@item 5090075SobrienThe @code{fixproto} script will sometimes add prototypes for the 5190075Sobrien@code{sigsetjmp} and @code{siglongjmp} functions that reference the 5290075Sobrien@code{jmp_buf} type before that type is defined. To work around this, 5390075Sobrienedit the offending file and place the typedef in front of the 5490075Sobrienprototypes. 5590075Sobrien 5690075Sobrien@item 5790075Sobrien@opindex pedantic-errors 5890075SobrienWhen @option{-pedantic-errors} is specified, GCC will incorrectly give 5990075Sobrienan error message when a function name is specified in an expression 6090075Sobrieninvolving the comma operator. 6190075Sobrien@end itemize 6290075Sobrien 6390075Sobrien@node Cross-Compiler Problems 6490075Sobrien@section Cross-Compiler Problems 6590075Sobrien 6690075SobrienYou may run into problems with cross compilation on certain machines, 6790075Sobrienfor several reasons. 6890075Sobrien 6990075Sobrien@itemize @bullet 7090075Sobrien@item 7190075SobrienCross compilation can run into trouble for certain machines because 7290075Sobriensome target machines' assemblers require floating point numbers to be 7390075Sobrienwritten as @emph{integer} constants in certain contexts. 7490075Sobrien 7590075SobrienThe compiler writes these integer constants by examining the floating 7690075Sobrienpoint value as an integer and printing that integer, because this is 7790075Sobriensimple to write and independent of the details of the floating point 7890075Sobrienrepresentation. But this does not work if the compiler is running on 7990075Sobriena different machine with an incompatible floating point format, or 8090075Sobrieneven a different byte-ordering. 8190075Sobrien 8290075SobrienIn addition, correct constant folding of floating point values 8390075Sobrienrequires representing them in the target machine's format. 8490075Sobrien(The C standard does not quite require this, but in practice 8590075Sobrienit is the only way to win.) 8690075Sobrien 8790075SobrienIt is now possible to overcome these problems by defining macros such 8890075Sobrienas @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of 8990075Sobrienwork for each target machine. 9090075Sobrien@xref{Cross-compilation,,Cross Compilation and Floating Point, 9190075Sobriengccint, GNU Compiler Collection (GCC) Internals}. 9290075Sobrien 9390075Sobrien@item 9490075SobrienAt present, the program @file{mips-tfile} which adds debug 9590075Sobriensupport to object files on MIPS systems does not work in a cross 9690075Sobriencompile environment. 9790075Sobrien@end itemize 9890075Sobrien 9990075Sobrien@node Interoperation 10090075Sobrien@section Interoperation 10190075Sobrien 10290075SobrienThis section lists various difficulties encountered in using GCC 10390075Sobrientogether with other compilers or with the assemblers, linkers, 10490075Sobrienlibraries and debuggers on certain systems. 10590075Sobrien 10690075Sobrien@itemize @bullet 10790075Sobrien@item 10890075SobrienG++ does not do name mangling in the same way as other C++ 10990075Sobriencompilers. This means that object files compiled with one compiler 11090075Sobriencannot be used with another. 11190075Sobrien 11290075SobrienThis effect is intentional, to protect you from more subtle problems. 11390075SobrienCompilers differ as to many internal details of C++ implementation, 11490075Sobrienincluding: how class instances are laid out, how multiple inheritance is 11590075Sobrienimplemented, and how virtual function calls are handled. If the name 11690075Sobrienencoding were made the same, your programs would link against libraries 11790075Sobrienprovided from other compilers---but the programs would then crash when 11890075Sobrienrun. Incompatible libraries are then detected at link time, rather than 11990075Sobrienat run time. 12090075Sobrien 12190075Sobrien@item 12290075SobrienOlder GDB versions sometimes fail to read the output of GCC version 12390075Sobrien2. If you have trouble, get GDB version 4.4 or later. 12490075Sobrien 12590075Sobrien@item 12690075Sobrien@cindex DBX 12790075SobrienDBX rejects some files produced by GCC, though it accepts similar 12890075Sobrienconstructs in output from PCC@. Until someone can supply a coherent 12990075Sobriendescription of what is valid DBX input and what is not, there is 13090075Sobriennothing I can do about these problems. You are on your own. 13190075Sobrien 13290075Sobrien@item 13390075SobrienThe GNU assembler (GAS) does not support PIC@. To generate PIC code, you 13490075Sobrienmust use some other assembler, such as @file{/bin/as}. 13590075Sobrien 13690075Sobrien@item 13790075SobrienOn some BSD systems, including some versions of Ultrix, use of profiling 13890075Sobriencauses static variable destructors (currently used only in C++) not to 13990075Sobrienbe run. 14090075Sobrien 14190075Sobrien@ignore 14290075Sobrien@cindex @code{vfork}, for the Sun-4 14390075Sobrien@item 14490075SobrienThere is a bug in @code{vfork} on the Sun-4 which causes the registers 14590075Sobrienof the child process to clobber those of the parent. Because of this, 14690075Sobrienprograms that call @code{vfork} are likely to lose when compiled 14790075Sobrienoptimized with GCC when the child code alters registers which contain 14890075SobrienC variables in the parent. This affects variables which are live in the 14990075Sobrienparent across the call to @code{vfork}. 15090075Sobrien 15190075SobrienIf you encounter this, you can work around the problem by declaring 15290075Sobrienvariables @code{volatile} in the function that calls @code{vfork}, until 15390075Sobrienthe problem goes away, or by not declaring them @code{register} and not 15490075Sobrienusing @option{-O} for those source files. 15590075Sobrien@end ignore 15690075Sobrien 15790075Sobrien@item 15890075SobrienOn some SGI systems, when you use @option{-lgl_s} as an option, 15990075Sobrienit gets translated magically to @samp{-lgl_s -lX11_s -lc_s}. 16090075SobrienNaturally, this does not happen when you use GCC@. 16190075SobrienYou must specify all three options explicitly. 16290075Sobrien 16390075Sobrien@item 16490075SobrienOn a Sparc, GCC aligns all values of type @code{double} on an 8-byte 16590075Sobrienboundary, and it expects every @code{double} to be so aligned. The Sun 16690075Sobriencompiler usually gives @code{double} values 8-byte alignment, with one 16790075Sobrienexception: function arguments of type @code{double} may not be aligned. 16890075Sobrien 16990075SobrienAs a result, if a function compiled with Sun CC takes the address of an 17090075Sobrienargument of type @code{double} and passes this pointer of type 17190075Sobrien@code{double *} to a function compiled with GCC, dereferencing the 17290075Sobrienpointer may cause a fatal signal. 17390075Sobrien 17490075SobrienOne way to solve this problem is to compile your entire program with GCC@. 17590075SobrienAnother solution is to modify the function that is compiled with 17690075SobrienSun CC to copy the argument into a local variable; local variables 17790075Sobrienare always properly aligned. A third solution is to modify the function 17890075Sobrienthat uses the pointer to dereference it via the following function 17990075Sobrien@code{access_double} instead of directly with @samp{*}: 18090075Sobrien 18190075Sobrien@smallexample 18290075Sobrieninline double 18390075Sobrienaccess_double (double *unaligned_ptr) 18490075Sobrien@{ 18590075Sobrien union d2i @{ double d; int i[2]; @}; 18690075Sobrien 18790075Sobrien union d2i *p = (union d2i *) unaligned_ptr; 18890075Sobrien union d2i u; 18990075Sobrien 19090075Sobrien u.i[0] = p->i[0]; 19190075Sobrien u.i[1] = p->i[1]; 19290075Sobrien 19390075Sobrien return u.d; 19490075Sobrien@} 19590075Sobrien@end smallexample 19690075Sobrien 19790075Sobrien@noindent 19890075SobrienStoring into the pointer can be done likewise with the same union. 19990075Sobrien 20090075Sobrien@item 20190075SobrienOn Solaris, the @code{malloc} function in the @file{libmalloc.a} library 20290075Sobrienmay allocate memory that is only 4 byte aligned. Since GCC on the 20390075SobrienSparc assumes that doubles are 8 byte aligned, this may result in a 20490075Sobrienfatal signal if doubles are stored in memory allocated by the 20590075Sobrien@file{libmalloc.a} library. 20690075Sobrien 20790075SobrienThe solution is to not use the @file{libmalloc.a} library. Use instead 20890075Sobrien@code{malloc} and related functions from @file{libc.a}; they do not have 20990075Sobrienthis problem. 21090075Sobrien 21190075Sobrien@item 21290075SobrienSun forgot to include a static version of @file{libdl.a} with some 21390075Sobrienversions of SunOS (mainly 4.1). This results in undefined symbols when 21490075Sobrienlinking static binaries (that is, if you use @option{-static}). If you 21590075Sobriensee undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen} 21690075Sobrienwhen linking, compile and link against the file 21790075Sobrien@file{mit/util/misc/dlsym.c} from the MIT version of X windows. 21890075Sobrien 21990075Sobrien@item 22090075SobrienThe 128-bit long double format that the Sparc port supports currently 22190075Sobrienworks by using the architecturally defined quad-word floating point 22290075Sobrieninstructions. Since there is no hardware that supports these 22390075Sobrieninstructions they must be emulated by the operating system. Long 22490075Sobriendoubles do not work in Sun OS versions 4.0.3 and earlier, because the 22590075Sobrienkernel emulator uses an obsolete and incompatible format. Long doubles 22690075Sobriendo not work in Sun OS version 4.1.1 due to a problem in a Sun library. 22790075SobrienLong doubles do work on Sun OS versions 4.1.2 and higher, but GCC 22890075Sobriendoes not enable them by default. Long doubles appear to work in Sun OS 22990075Sobrien5.x (Solaris 2.x). 23090075Sobrien 23190075Sobrien@item 23290075SobrienOn HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not 23390075Sobriencompile GCC correctly. We do not yet know why. However, GCC 23490075Sobriencompiled on earlier HP-UX versions works properly on HP-UX 9.01 and can 23590075Sobriencompile itself properly on 9.01. 23690075Sobrien 23790075Sobrien@item 23890075SobrienOn the HP PA machine, ADB sometimes fails to work on functions compiled 23990075Sobrienwith GCC@. Specifically, it fails to work on functions that use 24090075Sobrien@code{alloca} or variable-size arrays. This is because GCC doesn't 24190075Sobriengenerate HP-UX unwind descriptors for such functions. It may even be 24290075Sobrienimpossible to generate them. 24390075Sobrien 24490075Sobrien@item 24590075SobrienDebugging (@option{-g}) is not supported on the HP PA machine, unless you use 24690075Sobrienthe preliminary GNU tools. 24790075Sobrien 24890075Sobrien@item 24990075SobrienTaking the address of a label may generate errors from the HP-UX 25090075SobrienPA assembler. GAS for the PA does not have this problem. 25190075Sobrien 25290075Sobrien@item 25390075SobrienUsing floating point parameters for indirect calls to static functions 25490075Sobrienwill not work when using the HP assembler. There simply is no way for GCC 25590075Sobriento specify what registers hold arguments for static functions when using 25690075Sobrienthe HP assembler. GAS for the PA does not have this problem. 25790075Sobrien 25890075Sobrien@item 25990075SobrienIn extremely rare cases involving some very large functions you may 26090075Sobrienreceive errors from the HP linker complaining about an out of bounds 26190075Sobrienunconditional branch offset. This used to occur more often in previous 26290075Sobrienversions of GCC, but is now exceptionally rare. If you should run 26390075Sobrieninto it, you can work around by making your function smaller. 26490075Sobrien 26590075Sobrien@item 26690075SobrienGCC compiled code sometimes emits warnings from the HP-UX assembler of 26790075Sobrienthe form: 26890075Sobrien 26990075Sobrien@smallexample 27090075Sobrien(warning) Use of GR3 when 27190075Sobrien frame >= 8192 may cause conflict. 27290075Sobrien@end smallexample 27390075Sobrien 27490075SobrienThese warnings are harmless and can be safely ignored. 27590075Sobrien 27690075Sobrien@item 27790075SobrienOn the IBM RS/6000, compiling code of the form 27890075Sobrien 27990075Sobrien@smallexample 28090075Sobrienextern int foo; 28190075Sobrien 28290075Sobrien@dots{} foo @dots{} 28390075Sobrien 28490075Sobrienstatic int foo; 28590075Sobrien@end smallexample 28690075Sobrien 28790075Sobrien@noindent 28890075Sobrienwill cause the linker to report an undefined symbol @code{foo}. 28990075SobrienAlthough this behavior differs from most other systems, it is not a 29090075Sobrienbug because redefining an @code{extern} variable as @code{static} 29190075Sobrienis undefined in ISO C@. 29290075Sobrien 29390075Sobrien@item 29490075SobrienIn extremely rare cases involving some very large functions you may 29590075Sobrienreceive errors from the AIX Assembler complaining about a displacement 29690075Sobrienthat is too large. If you should run into it, you can work around by 29790075Sobrienmaking your function smaller. 29890075Sobrien 29990075Sobrien@item 30090075SobrienThe @file{libstdc++.a} library in GCC relies on the SVR4 dynamic 30190075Sobrienlinker semantics which merges global symbols between libraries and 30290075Sobrienapplications, especially necessary for C++ streams functionality. 30390075SobrienThis is not the default behavior of AIX shared libraries and dynamic 30490075Sobrienlinking. @file{libstdc++.a} is built on AIX with ``runtime-linking'' 30590075Sobrienenabled so that symbol merging can occur. To utilize this feature, 30690075Sobrienthe application linked with @file{libstdc++.a} must include the 30790075Sobrien@option{-Wl,-brtl} flag on the link line. G++ cannot impose this 30890075Sobrienbecause this option may interfere with the semantics of the user 30990075Sobrienprogram and users may not always use @samp{g++} to link his or her 31090075Sobrienapplication. Applications are not required to use the 31190075Sobrien@option{-Wl,-brtl} flag on the link line---the rest of the 31290075Sobrien@file{libstdc++.a} library which is not dependent on the symbol 31390075Sobrienmerging semantics will continue to function correctly. 31490075Sobrien 31590075Sobrien@item 31690075SobrienAn application can interpose its own definition of functions for 31790075Sobrienfunctions invoked by @file{libstdc++.a} with ``runtime-linking'' 31890075Sobrienenabled on AIX. To accomplish this the application must be linked 31990075Sobrienwith ``runtime-linking'' option and the functions explicitly must be 32090075Sobrienexported by the application (@option{-Wl,-brtl,-bE:exportfile}). 32190075Sobrien 32290075Sobrien@item 32390075SobrienAIX on the RS/6000 provides support (NLS) for environments outside of 32490075Sobrienthe United States. Compilers and assemblers use NLS to support 32590075Sobrienlocale-specific representations of various objects including 32690075Sobrienfloating-point numbers (@samp{.} vs @samp{,} for separating decimal 32790075Sobrienfractions). There have been problems reported where the library linked 32890075Sobrienwith GCC does not produce the same floating-point formats that the 32990075Sobrienassembler accepts. If you have this problem, set the @env{LANG} 33090075Sobrienenvironment variable to @samp{C} or @samp{En_US}. 33190075Sobrien 33290075Sobrien@item 33390075Sobrien@opindex fdollars-in-identifiers 33490075SobrienEven if you specify @option{-fdollars-in-identifiers}, 33590075Sobrienyou cannot successfully use @samp{$} in identifiers on the RS/6000 due 33690075Sobriento a restriction in the IBM assembler. GAS supports these 33790075Sobrienidentifiers. 33890075Sobrien 33990075Sobrien@item 34090075Sobrien@opindex mno-serialize-volatile 34190075SobrienThere is an assembler bug in versions of DG/UX prior to 5.4.2.01 that 34290075Sobrienoccurs when the @samp{fldcr} instruction is used. GCC uses 34390075Sobrien@samp{fldcr} on the 88100 to serialize volatile memory references. Use 34490075Sobrienthe option @option{-mno-serialize-volatile} if your version of the 34590075Sobrienassembler has this bug. 34690075Sobrien 34790075Sobrien@item 34890075SobrienOn VMS, GAS versions 1.38.1 and earlier may cause spurious warning 34990075Sobrienmessages from the linker. These warning messages complain of mismatched 35090075Sobrienpsect attributes. You can ignore them. 35190075Sobrien 35290075Sobrien@item 35390075SobrienOn NewsOS version 3, if you include both of the files @file{stddef.h} 35490075Sobrienand @file{sys/types.h}, you get an error because there are two typedefs 35590075Sobrienof @code{size_t}. You should change @file{sys/types.h} by adding these 35690075Sobrienlines around the definition of @code{size_t}: 35790075Sobrien 35890075Sobrien@smallexample 35990075Sobrien#ifndef _SIZE_T 36090075Sobrien#define _SIZE_T 36190075Sobrien@var{actual-typedef-here} 36290075Sobrien#endif 36390075Sobrien@end smallexample 36490075Sobrien 36590075Sobrien@cindex Alliant 36690075Sobrien@item 36790075SobrienOn the Alliant, the system's own convention for returning structures 36890075Sobrienand unions is unusual, and is not compatible with GCC no matter 36990075Sobrienwhat options are used. 37090075Sobrien 37190075Sobrien@cindex RT PC 37290075Sobrien@cindex IBM RT PC 37390075Sobrien@item 37490075Sobrien@opindex mhc-struct-return 37590075SobrienOn the IBM RT PC, the MetaWare HighC compiler (hc) uses a different 37690075Sobrienconvention for structure and union returning. Use the option 37790075Sobrien@option{-mhc-struct-return} to tell GCC to use a convention compatible 37890075Sobrienwith it. 37990075Sobrien 38090075Sobrien@cindex VAX calling convention 38190075Sobrien@cindex Ultrix calling convention 38290075Sobrien@item 38390075Sobrien@opindex fcall-saved 38490075SobrienOn Ultrix, the Fortran compiler expects registers 2 through 5 to be saved 38590075Sobrienby function calls. However, the C compiler uses conventions compatible 38690075Sobrienwith BSD Unix: registers 2 through 5 may be clobbered by function calls. 38790075Sobrien 38890075SobrienGCC uses the same convention as the Ultrix C compiler. You can use 38990075Sobrienthese options to produce code compatible with the Fortran compiler: 39090075Sobrien 39190075Sobrien@smallexample 39290075Sobrien-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 39390075Sobrien@end smallexample 39490075Sobrien 39590075Sobrien@item 39690075SobrienOn the WE32k, you may find that programs compiled with GCC do not 39790075Sobrienwork with the standard shared C library. You may need to link with 39890075Sobrienthe ordinary C compiler. If you do so, you must specify the following 39990075Sobrienoptions: 40090075Sobrien 40190075Sobrien@smallexample 40290075Sobrien-L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s 40390075Sobrien@end smallexample 40490075Sobrien 40590075SobrienThe first specifies where to find the library @file{libgcc.a} 40690075Sobrienspecified with the @option{-lgcc} option. 40790075Sobrien 40890075SobrienGCC does linking by invoking @command{ld}, just as @command{cc} does, and 40990075Sobrienthere is no reason why it @emph{should} matter which compilation program 41090075Sobrienyou use to invoke @command{ld}. If someone tracks this problem down, 41190075Sobrienit can probably be fixed easily. 41290075Sobrien 41390075Sobrien@item 41490075SobrienOn the Alpha, you may get assembler errors about invalid syntax as a 41590075Sobrienresult of floating point constants. This is due to a bug in the C 41690075Sobrienlibrary functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid 41790075Sobrienfloating point numbers, they sometimes print @samp{NaN}. 41890075Sobrien 41990075Sobrien@item 42090075SobrienOn Irix 4.0.5F (and perhaps in some other versions), an assembler bug 42190075Sobriensometimes reorders instructions incorrectly when optimization is turned 42290075Sobrienon. If you think this may be happening to you, try using the GNU 42390075Sobrienassembler; GAS version 2.1 supports ECOFF on Irix. 42490075Sobrien 42590075Sobrien@opindex noasmopt 42690075SobrienOr use the @option{-noasmopt} option when you compile GCC with itself, 42790075Sobrienand then again when you compile your program. (This is a temporary 42890075Sobrienkludge to turn off assembler optimization on Irix.) If this proves to 42990075Sobrienbe what you need, edit the assembler spec in the file @file{specs} so 43090075Sobrienthat it unconditionally passes @option{-O0} to the assembler, and never 43190075Sobrienpasses @option{-O2} or @option{-O3}. 43290075Sobrien@end itemize 43390075Sobrien 43490075Sobrien@node External Bugs 43590075Sobrien@section Problems Compiling Certain Programs 43690075Sobrien 43790075Sobrien@c prevent bad page break with this line 43890075SobrienCertain programs have problems compiling. 43990075Sobrien 44090075Sobrien@itemize @bullet 44190075Sobrien@item 44290075SobrienParse errors may occur compiling X11 on a Decstation running Ultrix 4.2 44390075Sobrienbecause of problems in DEC's versions of the X11 header files 44490075Sobrien@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding 44590075Sobrien@option{-I/usr/include/mit} to use the MIT versions of the header files, 44690075Sobrienusing the @option{-traditional} switch to turn off ISO C, or fixing the 44790075Sobrienheader files by adding this: 44890075Sobrien 44990075Sobrien@example 45090075Sobrien#ifdef __STDC__ 45190075Sobrien#define NeedFunctionPrototypes 0 45290075Sobrien#endif 45390075Sobrien@end example 45490075Sobrien 45590075Sobrien@item 45690075SobrienOn various 386 Unix systems derived from System V, including SCO, ISC, 45790075Sobrienand ESIX, you may get error messages about running out of virtual memory 45890075Sobrienwhile compiling certain programs. 45990075Sobrien 46090075SobrienYou can prevent this problem by linking GCC with the GNU malloc 46190075Sobrien(which thus replaces the malloc that comes with the system). GNU malloc 46290075Sobrienis available as a separate package, and also in the file 46390075Sobrien@file{src/gmalloc.c} in the GNU Emacs 19 distribution. 46490075Sobrien 46590075SobrienIf you have installed GNU malloc as a separate library package, use this 46690075Sobrienoption when you relink GCC: 46790075Sobrien 46890075Sobrien@example 46990075SobrienMALLOC=/usr/local/lib/libgmalloc.a 47090075Sobrien@end example 47190075Sobrien 47290075SobrienAlternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy 47390075Sobrienthe object file to @file{gmalloc.o} and use this option when you relink 47490075SobrienGCC: 47590075Sobrien 47690075Sobrien@example 47790075SobrienMALLOC=gmalloc.o 47890075Sobrien@end example 47990075Sobrien@end itemize 48090075Sobrien 48190075Sobrien@node Incompatibilities 48290075Sobrien@section Incompatibilities of GCC 48390075Sobrien@cindex incompatibilities of GCC 48490075Sobrien@opindex traditional 48590075Sobrien 48690075SobrienThere are several noteworthy incompatibilities between GNU C and K&R 48790075Sobrien(non-ISO) versions of C@. The @option{-traditional} option 48890075Sobrieneliminates many of these incompatibilities, @emph{but not all}, by 48990075Sobrientelling GCC to behave like a K&R C compiler. 49090075Sobrien 49190075Sobrien@itemize @bullet 49290075Sobrien@cindex string constants 49390075Sobrien@cindex read-only strings 49490075Sobrien@cindex shared strings 49590075Sobrien@item 49690075SobrienGCC normally makes string constants read-only. If several 49790075Sobrienidentical-looking string constants are used, GCC stores only one 49890075Sobriencopy of the string. 49990075Sobrien 50090075Sobrien@cindex @code{mktemp}, and constant strings 50190075SobrienOne consequence is that you cannot call @code{mktemp} with a string 50290075Sobrienconstant argument. The function @code{mktemp} always alters the 50390075Sobrienstring its argument points to. 50490075Sobrien 50590075Sobrien@cindex @code{sscanf}, and constant strings 50690075Sobrien@cindex @code{fscanf}, and constant strings 50790075Sobrien@cindex @code{scanf}, and constant strings 50890075SobrienAnother consequence is that @code{sscanf} does not work on some systems 50990075Sobrienwhen passed a string constant as its format control string or input. 51090075SobrienThis is because @code{sscanf} incorrectly tries to write into the string 51190075Sobrienconstant. Likewise @code{fscanf} and @code{scanf}. 51290075Sobrien 51390075Sobrien@opindex fwritable-strings 51490075SobrienThe best solution to these problems is to change the program to use 51590075Sobrien@code{char}-array variables with initialization strings for these 51690075Sobrienpurposes instead of string constants. But if this is not possible, 51790075Sobrienyou can use the @option{-fwritable-strings} flag, which directs GCC 51890075Sobriento handle string constants the same way most C compilers do. 51990075Sobrien@option{-traditional} also has this effect, among others. 52090075Sobrien 52190075Sobrien@item 52290075Sobrien@code{-2147483648} is positive. 52390075Sobrien 52490075SobrienThis is because 2147483648 cannot fit in the type @code{int}, so 52590075Sobrien(following the ISO C rules) its data type is @code{unsigned long int}. 52690075SobrienNegating this value yields 2147483648 again. 52790075Sobrien 52890075Sobrien@item 52990075SobrienGCC does not substitute macro arguments when they appear inside of 53090075Sobrienstring constants. For example, the following macro in GCC 53190075Sobrien 53290075Sobrien@example 53390075Sobrien#define foo(a) "a" 53490075Sobrien@end example 53590075Sobrien 53690075Sobrien@noindent 53790075Sobrienwill produce output @code{"a"} regardless of what the argument @var{a} is. 53890075Sobrien 53990075SobrienThe @option{-traditional} option directs GCC to handle such cases 54090075Sobrien(among others) in the old-fashioned (non-ISO) fashion. 54190075Sobrien 54290075Sobrien@cindex @code{setjmp} incompatibilities 54390075Sobrien@cindex @code{longjmp} incompatibilities 54490075Sobrien@item 54590075SobrienWhen you use @code{setjmp} and @code{longjmp}, the only automatic 54690075Sobrienvariables guaranteed to remain valid are those declared 54790075Sobrien@code{volatile}. This is a consequence of automatic register 54890075Sobrienallocation. Consider this function: 54990075Sobrien 55090075Sobrien@example 55190075Sobrienjmp_buf j; 55290075Sobrien 55390075Sobrienfoo () 55490075Sobrien@{ 55590075Sobrien int a, b; 55690075Sobrien 55790075Sobrien a = fun1 (); 55890075Sobrien if (setjmp (j)) 55990075Sobrien return a; 56090075Sobrien 56190075Sobrien a = fun2 (); 56290075Sobrien /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ 56390075Sobrien return a + fun3 (); 56490075Sobrien@} 56590075Sobrien@end example 56690075Sobrien 56790075SobrienHere @code{a} may or may not be restored to its first value when the 56890075Sobrien@code{longjmp} occurs. If @code{a} is allocated in a register, then 56990075Sobrienits first value is restored; otherwise, it keeps the last value stored 57090075Sobrienin it. 57190075Sobrien 57290075Sobrien@opindex W 57390075SobrienIf you use the @option{-W} option with the @option{-O} option, you will 57490075Sobrienget a warning when GCC thinks such a problem might be possible. 57590075Sobrien 57690075SobrienThe @option{-traditional} option directs GCC to put variables in 57790075Sobrienthe stack by default, rather than in registers, in functions that 57890075Sobriencall @code{setjmp}. This results in the behavior found in 57990075Sobrientraditional C compilers. 58090075Sobrien 58190075Sobrien@item 58290075SobrienPrograms that use preprocessing directives in the middle of macro 58390075Sobrienarguments do not work with GCC@. For example, a program like this 58490075Sobrienwill not work: 58590075Sobrien 58690075Sobrien@example 58790075Sobrien@group 58890075Sobrienfoobar ( 58990075Sobrien#define luser 59090075Sobrien hack) 59190075Sobrien@end group 59290075Sobrien@end example 59390075Sobrien 59490075SobrienISO C does not permit such a construct. It would make sense to support 59590075Sobrienit when @option{-traditional} is used, but it is too much work to 59690075Sobrienimplement. 59790075Sobrien 59890075Sobrien@item 59990075SobrienK&R compilers allow comments to cross over an inclusion boundary 60090075Sobrien(i.e.@: started in an include file and ended in the including file). I think 60190075Sobrienthis would be quite ugly and can't imagine it could be needed. 60290075Sobrien 60390075Sobrien@cindex external declaration scope 60490075Sobrien@cindex scope of external declarations 60590075Sobrien@cindex declaration scope 60690075Sobrien@item 60790075SobrienDeclarations of external variables and functions within a block apply 60890075Sobrienonly to the block containing the declaration. In other words, they 60990075Sobrienhave the same scope as any other declaration in the same place. 61090075Sobrien 61190075SobrienIn some other C compilers, a @code{extern} declaration affects all the 61290075Sobrienrest of the file even if it happens within a block. 61390075Sobrien 61490075SobrienThe @option{-traditional} option directs GCC to treat all @code{extern} 61590075Sobriendeclarations as global, like traditional compilers. 61690075Sobrien 61790075Sobrien@item 61890075SobrienIn traditional C, you can combine @code{long}, etc., with a typedef name, 61990075Sobrienas shown here: 62090075Sobrien 62190075Sobrien@example 62290075Sobrientypedef int foo; 62390075Sobrientypedef long foo bar; 62490075Sobrien@end example 62590075Sobrien 62690075SobrienIn ISO C, this is not allowed: @code{long} and other type modifiers 62790075Sobrienrequire an explicit @code{int}. Because this criterion is expressed 62890075Sobrienby Bison grammar rules rather than C code, the @option{-traditional} 62990075Sobrienflag cannot alter it. 63090075Sobrien 63190075Sobrien@cindex typedef names as function parameters 63290075Sobrien@item 63390075SobrienPCC allows typedef names to be used as function parameters. The 63490075Sobriendifficulty described immediately above applies here too. 63590075Sobrien 63690075Sobrien@item 63790075SobrienWhen in @option{-traditional} mode, GCC allows the following erroneous 63890075Sobrienpair of declarations to appear together in a given scope: 63990075Sobrien 64090075Sobrien@example 64190075Sobrientypedef int foo; 64290075Sobrientypedef foo foo; 64390075Sobrien@end example 64490075Sobrien 64590075Sobrien@item 64690075SobrienGCC treats all characters of identifiers as significant, even when in 64790075Sobrien@option{-traditional} mode. According to K&R-1 (2.2), ``No more than the 64890075Sobrienfirst eight characters are significant, although more may be used.''. 64990075SobrienAlso according to K&R-1 (2.2), ``An identifier is a sequence of letters 65090075Sobrienand digits; the first character must be a letter. The underscore _ 65190075Sobriencounts as a letter.'', but GCC also allows dollar signs in identifiers. 65290075Sobrien 65390075Sobrien@cindex whitespace 65490075Sobrien@item 65590075SobrienPCC allows whitespace in the middle of compound assignment operators 65690075Sobriensuch as @samp{+=}. GCC, following the ISO standard, does not 65790075Sobrienallow this. The difficulty described immediately above applies here 65890075Sobrientoo. 65990075Sobrien 66090075Sobrien@cindex apostrophes 66190075Sobrien@cindex ' 66290075Sobrien@item 66390075SobrienGCC complains about unterminated character constants inside of 66490075Sobrienpreprocessing conditionals that fail. Some programs have English 66590075Sobriencomments enclosed in conditionals that are guaranteed to fail; if these 66690075Sobriencomments contain apostrophes, GCC will probably report an error. For 66790075Sobrienexample, this code would produce an error: 66890075Sobrien 66990075Sobrien@example 67090075Sobrien#if 0 67190075SobrienYou can't expect this to work. 67290075Sobrien#endif 67390075Sobrien@end example 67490075Sobrien 67590075SobrienThe best solution to such a problem is to put the text into an actual 67690075SobrienC comment delimited by @samp{/*@dots{}*/}. However, 67790075Sobrien@option{-traditional} suppresses these error messages. 67890075Sobrien 67990075Sobrien@item 68090075SobrienMany user programs contain the declaration @samp{long time ();}. In the 68190075Sobrienpast, the system header files on many systems did not actually declare 68290075Sobrien@code{time}, so it did not matter what type your program declared it to 68390075Sobrienreturn. But in systems with ISO C headers, @code{time} is declared to 68490075Sobrienreturn @code{time_t}, and if that is not the same as @code{long}, then 68590075Sobrien@samp{long time ();} is erroneous. 68690075Sobrien 68790075SobrienThe solution is to change your program to use appropriate system headers 68890075Sobrien(@code{<time.h>} on systems with ISO C headers) and not to declare 68990075Sobrien@code{time} if the system header files declare it, or failing that to 69090075Sobrienuse @code{time_t} as the return type of @code{time}. 69190075Sobrien 69290075Sobrien@cindex @code{float} as function value type 69390075Sobrien@item 69490075SobrienWhen compiling functions that return @code{float}, PCC converts it to 69590075Sobriena double. GCC actually returns a @code{float}. If you are concerned 69690075Sobrienwith PCC compatibility, you should declare your functions to return 69790075Sobrien@code{double}; you might as well say what you mean. 69890075Sobrien 69990075Sobrien@cindex structures 70090075Sobrien@cindex unions 70190075Sobrien@item 70290075SobrienWhen compiling functions that return structures or unions, GCC 70390075Sobrienoutput code normally uses a method different from that used on most 70490075Sobrienversions of Unix. As a result, code compiled with GCC cannot call 70590075Sobriena structure-returning function compiled with PCC, and vice versa. 70690075Sobrien 70790075SobrienThe method used by GCC is as follows: a structure or union which is 70890075Sobrien1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union 70990075Sobrienwith any other size is stored into an address supplied by the caller 71090075Sobrien(usually in a special, fixed register, but on some machines it is passed 71190075Sobrienon the stack). The machine-description macros @code{STRUCT_VALUE} and 71290075Sobrien@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address. 71390075Sobrien 71490075SobrienBy contrast, PCC on most target machines returns structures and unions 71590075Sobrienof any size by copying the data into an area of static storage, and then 71690075Sobrienreturning the address of that storage as if it were a pointer value. 71790075SobrienThe caller must copy the data from that memory area to the place where 71890075Sobrienthe value is wanted. GCC does not use this method because it is 71990075Sobrienslower and nonreentrant. 72090075Sobrien 72190075SobrienOn some newer machines, PCC uses a reentrant convention for all 72290075Sobrienstructure and union returning. GCC on most of these machines uses a 72390075Sobriencompatible convention when returning structures and unions in memory, 72490075Sobrienbut still returns small structures and unions in registers. 72590075Sobrien 72690075Sobrien@opindex fpcc-struct-return 72790075SobrienYou can tell GCC to use a compatible convention for all structure and 72890075Sobrienunion returning with the option @option{-fpcc-struct-return}. 72990075Sobrien 73090075Sobrien@cindex preprocessing tokens 73190075Sobrien@cindex preprocessing numbers 73290075Sobrien@item 73390075SobrienGCC complains about program fragments such as @samp{0x74ae-0x4000} 73490075Sobrienwhich appear to be two hexadecimal constants separated by the minus 73590075Sobrienoperator. Actually, this string is a single @dfn{preprocessing token}. 73690075SobrienEach such token must correspond to one token in C@. Since this does not, 73790075SobrienGCC prints an error message. Although it may appear obvious that what 73890075Sobrienis meant is an operator and two values, the ISO C standard specifically 73990075Sobrienrequires that this be treated as erroneous. 74090075Sobrien 74190075SobrienA @dfn{preprocessing token} is a @dfn{preprocessing number} if it 74290075Sobrienbegins with a digit and is followed by letters, underscores, digits, 74390075Sobrienperiods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, 74490075Sobrien@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89 74590075Sobrienmode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot 74690075Sobrienappear in preprocessing numbers.) 74790075Sobrien 74890075SobrienTo make the above program fragment valid, place whitespace in front of 74990075Sobrienthe minus sign. This whitespace will end the preprocessing number. 75090075Sobrien@end itemize 75190075Sobrien 75290075Sobrien@node Fixed Headers 75390075Sobrien@section Fixed Header Files 75490075Sobrien 75590075SobrienGCC needs to install corrected versions of some system header files. 75690075SobrienThis is because most target systems have some header files that won't 75790075Sobrienwork with GCC unless they are changed. Some have bugs, some are 75890075Sobrienincompatible with ISO C, and some depend on special features of other 75990075Sobriencompilers. 76090075Sobrien 76190075SobrienInstalling GCC automatically creates and installs the fixed header 76290075Sobrienfiles, by running a program called @code{fixincludes} (or for certain 76390075Sobrientargets an alternative such as @code{fixinc.svr4}). Normally, you 76490075Sobriendon't need to pay attention to this. But there are cases where it 76590075Sobriendoesn't do the right thing automatically. 76690075Sobrien 76790075Sobrien@itemize @bullet 76890075Sobrien@item 76990075SobrienIf you update the system's header files, such as by installing a new 77090075Sobriensystem version, the fixed header files of GCC are not automatically 77190075Sobrienupdated. The easiest way to update them is to reinstall GCC@. (If 77290075Sobrienyou want to be clever, look in the makefile and you can find a 77390075Sobrienshortcut.) 77490075Sobrien 77590075Sobrien@item 77690075SobrienOn some systems, in particular SunOS 4, header file directories contain 77790075Sobrienmachine-specific symbolic links in certain places. This makes it 77890075Sobrienpossible to share most of the header files among hosts running the 77990075Sobriensame version of SunOS 4 on different machine models. 78090075Sobrien 78190075SobrienThe programs that fix the header files do not understand this special 78290075Sobrienway of using symbolic links; therefore, the directory of fixed header 78390075Sobrienfiles is good only for the machine model used to build it. 78490075Sobrien 78590075SobrienIn SunOS 4, only programs that look inside the kernel will notice the 78690075Sobriendifference between machine models. Therefore, for most purposes, you 78790075Sobrienneed not be concerned about this. 78890075Sobrien 78990075SobrienIt is possible to make separate sets of fixed header files for the 79090075Sobriendifferent machine models, and arrange a structure of symbolic links so 79190075Sobrienas to use the proper set, but you'll have to do this by hand. 79290075Sobrien 79390075Sobrien@item 79490075SobrienOn Lynxos, GCC by default does not fix the header files. This is 79590075Sobrienbecause bugs in the shell cause the @code{fixincludes} script to fail. 79690075Sobrien 79790075SobrienThis means you will encounter problems due to bugs in the system header 79890075Sobrienfiles. It may be no comfort that they aren't GCC's fault, but it 79990075Sobriendoes mean that there's nothing for us to do about them. 80090075Sobrien@end itemize 80190075Sobrien 80290075Sobrien@node Standard Libraries 80390075Sobrien@section Standard Libraries 80490075Sobrien 80590075Sobrien@opindex Wall 80690075SobrienGCC by itself attempts to be a conforming freestanding implementation. 80790075Sobrien@xref{Standards,,Language Standards Supported by GCC}, for details of 80890075Sobrienwhat this means. Beyond the library facilities required of such an 80990075Sobrienimplementation, the rest of the C library is supplied by the vendor of 81090075Sobrienthe operating system. If that C library doesn't conform to the C 81190075Sobrienstandards, then your programs might get warnings (especially when using 81290075Sobrien@option{-Wall}) that you don't expect. 81390075Sobrien 81490075SobrienFor example, the @code{sprintf} function on SunOS 4.1.3 returns 81590075Sobrien@code{char *} while the C standard says that @code{sprintf} returns an 81690075Sobrien@code{int}. The @code{fixincludes} program could make the prototype for 81790075Sobrienthis function match the Standard, but that would be wrong, since the 81890075Sobrienfunction will still return @code{char *}. 81990075Sobrien 82090075SobrienIf you need a Standard compliant library, then you need to find one, as 82190075SobrienGCC does not provide one. The GNU C library (called @code{glibc}) 82290075Sobrienprovides ISO C, POSIX, BSD, SystemV and X/Open compatibility for 82390075SobrienGNU/Linux and HURD-based GNU systems; no recent version of it supports 82490075Sobrienother systems, though some very old versions did. Version 2.2 of the 82590075SobrienGNU C library includes nearly complete C99 support. You could also ask 82690075Sobrienyour operating system vendor if newer libraries are available. 82790075Sobrien 82890075Sobrien@node Disappointments 82990075Sobrien@section Disappointments and Misunderstandings 83090075Sobrien 83190075SobrienThese problems are perhaps regrettable, but we don't know any practical 83290075Sobrienway around them. 83390075Sobrien 83490075Sobrien@itemize @bullet 83590075Sobrien@item 83690075SobrienCertain local variables aren't recognized by debuggers when you compile 83790075Sobrienwith optimization. 83890075Sobrien 83990075SobrienThis occurs because sometimes GCC optimizes the variable out of 84090075Sobrienexistence. There is no way to tell the debugger how to compute the 84190075Sobrienvalue such a variable ``would have had'', and it is not clear that would 84290075Sobrienbe desirable anyway. So GCC simply does not mention the eliminated 84390075Sobrienvariable when it writes debugging information. 84490075Sobrien 84590075SobrienYou have to expect a certain amount of disagreement between the 84690075Sobrienexecutable and your source code, when you use optimization. 84790075Sobrien 84890075Sobrien@cindex conflicting types 84990075Sobrien@cindex scope of declaration 85090075Sobrien@item 85190075SobrienUsers often think it is a bug when GCC reports an error for code 85290075Sobrienlike this: 85390075Sobrien 85490075Sobrien@example 85590075Sobrienint foo (struct mumble *); 85690075Sobrien 85790075Sobrienstruct mumble @{ @dots{} @}; 85890075Sobrien 85990075Sobrienint foo (struct mumble *x) 86090075Sobrien@{ @dots{} @} 86190075Sobrien@end example 86290075Sobrien 86390075SobrienThis code really is erroneous, because the scope of @code{struct 86490075Sobrienmumble} in the prototype is limited to the argument list containing it. 86590075SobrienIt does not refer to the @code{struct mumble} defined with file scope 86690075Sobrienimmediately below---they are two unrelated types with similar names in 86790075Sobriendifferent scopes. 86890075Sobrien 86990075SobrienBut in the definition of @code{foo}, the file-scope type is used 87090075Sobrienbecause that is available to be inherited. Thus, the definition and 87190075Sobrienthe prototype do not match, and you get an error. 87290075Sobrien 87390075SobrienThis behavior may seem silly, but it's what the ISO standard specifies. 87490075SobrienIt is easy enough for you to make your code work by moving the 87590075Sobriendefinition of @code{struct mumble} above the prototype. It's not worth 87690075Sobrienbeing incompatible with ISO C just to avoid an error for the example 87790075Sobrienshown above. 87890075Sobrien 87990075Sobrien@item 88090075SobrienAccesses to bit-fields even in volatile objects works by accessing larger 88190075Sobrienobjects, such as a byte or a word. You cannot rely on what size of 88290075Sobrienobject is accessed in order to read or write the bit-field; it may even 88390075Sobrienvary for a given bit-field according to the precise usage. 88490075Sobrien 88590075SobrienIf you care about controlling the amount of memory that is accessed, use 88690075Sobrienvolatile but do not use bit-fields. 88790075Sobrien 88890075Sobrien@item 88990075SobrienGCC comes with shell scripts to fix certain known problems in system 89090075Sobrienheader files. They install corrected copies of various header files in 89190075Sobriena special directory where only GCC will normally look for them. The 89290075Sobrienscripts adapt to various systems by searching all the system header 89390075Sobrienfiles for the problem cases that we know about. 89490075Sobrien 89590075SobrienIf new system header files are installed, nothing automatically arranges 89690075Sobriento update the corrected header files. You will have to reinstall GCC 89790075Sobriento fix the new header files. More specifically, go to the build 89890075Sobriendirectory and delete the files @file{stmp-fixinc} and 89990075Sobrien@file{stmp-headers}, and the subdirectory @code{include}; then do 90090075Sobrien@samp{make install} again. 90190075Sobrien 90290075Sobrien@item 90390075Sobrien@cindex floating point precision 90490075SobrienOn 68000 and x86 systems, for instance, you can get paradoxical results 90590075Sobrienif you test the precise values of floating point numbers. For example, 90690075Sobrienyou can find that a floating point value which is not a NaN is not equal 90790075Sobriento itself. This results from the fact that the floating point registers 90890075Sobrienhold a few more bits of precision than fit in a @code{double} in memory. 90990075SobrienCompiled code moves values between memory and floating point registers 91090075Sobrienat its convenience, and moving them into memory truncates them. 91190075Sobrien 91290075Sobrien@opindex ffloat-store 91390075SobrienYou can partially avoid this problem by using the @option{-ffloat-store} 91490075Sobrienoption (@pxref{Optimize Options}). 91590075Sobrien 91690075Sobrien@item 91790075SobrienOn the MIPS, variable argument functions using @file{varargs.h} 91890075Sobriencannot have a floating point value for the first argument. The 91990075Sobrienreason for this is that in the absence of a prototype in scope, 92090075Sobrienif the first argument is a floating point, it is passed in a 92190075Sobrienfloating point register, rather than an integer register. 92290075Sobrien 92390075SobrienIf the code is rewritten to use the ISO standard @file{stdarg.h} 92490075Sobrienmethod of variable arguments, and the prototype is in scope at 92590075Sobrienthe time of the call, everything will work fine. 92690075Sobrien 92790075Sobrien@item 92890075SobrienOn the H8/300 and H8/300H, variable argument functions must be 92990075Sobrienimplemented using the ISO standard @file{stdarg.h} method of 93090075Sobrienvariable arguments. Furthermore, calls to functions using @file{stdarg.h} 93190075Sobrienvariable arguments must have a prototype for the called function 93290075Sobrienin scope at the time of the call. 93390075Sobrien 93490075Sobrien@item 93590075SobrienOn AIX and other platforms without weak symbol support, templates 93690075Sobrienneed to be instantiated explicitly and symbols for static members 93790075Sobrienof templates will not be generated. 93890075Sobrien@end itemize 93990075Sobrien 94090075Sobrien@node C++ Misunderstandings 94190075Sobrien@section Common Misunderstandings with GNU C++ 94290075Sobrien 94390075Sobrien@cindex misunderstandings in C++ 94490075Sobrien@cindex surprises in C++ 94590075Sobrien@cindex C++ misunderstandings 94690075SobrienC++ is a complex language and an evolving one, and its standard 94790075Sobriendefinition (the ISO C++ standard) was only recently completed. As a 94890075Sobrienresult, your C++ compiler may occasionally surprise you, even when its 94990075Sobrienbehavior is correct. This section discusses some areas that frequently 95090075Sobriengive rise to questions of this sort. 95190075Sobrien 95290075Sobrien@menu 95390075Sobrien* Static Definitions:: Static member declarations are not definitions 95490075Sobrien* Temporaries:: Temporaries may vanish before you expect 95590075Sobrien* Copy Assignment:: Copy Assignment operators copy virtual bases twice 95690075Sobrien@end menu 95790075Sobrien 95890075Sobrien@node Static Definitions 95990075Sobrien@subsection Declare @emph{and} Define Static Members 96090075Sobrien 96190075Sobrien@cindex C++ static data, declaring and defining 96290075Sobrien@cindex static data in C++, declaring and defining 96390075Sobrien@cindex declaring static data in C++ 96490075Sobrien@cindex defining static data in C++ 96590075SobrienWhen a class has static data members, it is not enough to @emph{declare} 96690075Sobrienthe static member; you must also @emph{define} it. For example: 96790075Sobrien 96890075Sobrien@example 96990075Sobrienclass Foo 97090075Sobrien@{ 97190075Sobrien @dots{} 97290075Sobrien void method(); 97390075Sobrien static int bar; 97490075Sobrien@}; 97590075Sobrien@end example 97690075Sobrien 97790075SobrienThis declaration only establishes that the class @code{Foo} has an 97890075Sobrien@code{int} named @code{Foo::bar}, and a member function named 97990075Sobrien@code{Foo::method}. But you still need to define @emph{both} 98090075Sobrien@code{method} and @code{bar} elsewhere. According to the ISO 98190075Sobrienstandard, you must supply an initializer in one (and only one) source 98290075Sobrienfile, such as: 98390075Sobrien 98490075Sobrien@example 98590075Sobrienint Foo::bar = 0; 98690075Sobrien@end example 98790075Sobrien 98890075SobrienOther C++ compilers may not correctly implement the standard behavior. 98990075SobrienAs a result, when you switch to @code{g++} from one of these compilers, 99090075Sobrienyou may discover that a program that appeared to work correctly in fact 99190075Sobriendoes not conform to the standard: @code{g++} reports as undefined 99290075Sobriensymbols any static data members that lack definitions. 99390075Sobrien 99490075Sobrien@node Temporaries 99590075Sobrien@subsection Temporaries May Vanish Before You Expect 99690075Sobrien 99790075Sobrien@cindex temporaries, lifetime of 99890075Sobrien@cindex portions of temporary objects, pointers to 99990075SobrienIt is dangerous to use pointers or references to @emph{portions} of a 100090075Sobrientemporary object. The compiler may very well delete the object before 100190075Sobrienyou expect it to, leaving a pointer to garbage. The most common place 100290075Sobrienwhere this problem crops up is in classes like string classes, 100390075Sobrienespecially ones that define a conversion function to type @code{char *} 100490075Sobrienor @code{const char *}---which is one reason why the standard 100590075Sobrien@code{string} class requires you to call the @code{c_str} member 100690075Sobrienfunction. However, any class that returns a pointer to some internal 100790075Sobrienstructure is potentially subject to this problem. 100890075Sobrien 100990075SobrienFor example, a program may use a function @code{strfunc} that returns 101090075Sobrien@code{string} objects, and another function @code{charfunc} that 101190075Sobrienoperates on pointers to @code{char}: 101290075Sobrien 101390075Sobrien@example 101490075Sobrienstring strfunc (); 101590075Sobrienvoid charfunc (const char *); 101690075Sobrien 101790075Sobrienvoid 101890075Sobrienf () 101990075Sobrien@{ 102090075Sobrien const char *p = strfunc().c_str(); 102190075Sobrien @dots{} 102290075Sobrien charfunc (p); 102390075Sobrien @dots{} 102490075Sobrien charfunc (p); 102590075Sobrien@} 102690075Sobrien@end example 102790075Sobrien 102890075Sobrien@noindent 102990075SobrienIn this situation, it may seem reasonable to save a pointer to the C 103090075Sobrienstring returned by the @code{c_str} member function and use that rather 103190075Sobrienthan call @code{c_str} repeatedly. However, the temporary string 103290075Sobriencreated by the call to @code{strfunc} is destroyed after @code{p} is 103390075Sobrieninitialized, at which point @code{p} is left pointing to freed memory. 103490075Sobrien 103590075SobrienCode like this may run successfully under some other compilers, 103690075Sobrienparticularly obsolete cfront-based compilers that delete temporaries 103790075Sobrienalong with normal local variables. However, the GNU C++ behavior is 103890075Sobrienstandard-conforming, so if your program depends on late destruction of 103990075Sobrientemporaries it is not portable. 104090075Sobrien 104190075SobrienThe safe way to write such code is to give the temporary a name, which 104290075Sobrienforces it to remain until the end of the scope of the name. For 104390075Sobrienexample: 104490075Sobrien 104590075Sobrien@example 104690075Sobrienstring& tmp = strfunc (); 104790075Sobriencharfunc (tmp.c_str ()); 104890075Sobrien@end example 104990075Sobrien 105090075Sobrien@node Copy Assignment 105190075Sobrien@subsection Implicit Copy-Assignment for Virtual Bases 105290075Sobrien 105390075SobrienWhen a base class is virtual, only one subobject of the base class 105490075Sobrienbelongs to each full object. Also, the constructors and destructors are 105590075Sobrieninvoked only once, and called from the most-derived class. However, such 105690075Sobrienobjects behave unspecified when being assigned. For example: 105790075Sobrien 105890075Sobrien@example 105990075Sobrienstruct Base@{ 106090075Sobrien char *name; 106190075Sobrien Base(char *n) : name(strdup(n))@{@} 106290075Sobrien Base& operator= (const Base& other)@{ 106390075Sobrien free (name); 106490075Sobrien name = strdup (other.name); 106590075Sobrien @} 106690075Sobrien@}; 106790075Sobrien 106890075Sobrienstruct A:virtual Base@{ 106990075Sobrien int val; 107090075Sobrien A():Base("A")@{@} 107190075Sobrien@}; 107290075Sobrien 107390075Sobrienstruct B:virtual Base@{ 107490075Sobrien int bval; 107590075Sobrien B():Base("B")@{@} 107690075Sobrien@}; 107790075Sobrien 107890075Sobrienstruct Derived:public A, public B@{ 107990075Sobrien Derived():Base("Derived")@{@} 108090075Sobrien@}; 108190075Sobrien 108290075Sobrienvoid func(Derived &d1, Derived &d2) 108390075Sobrien@{ 108490075Sobrien d1 = d2; 108590075Sobrien@} 108690075Sobrien@end example 108790075Sobrien 108890075SobrienThe C++ standard specifies that @samp{Base::Base} is only called once 108990075Sobrienwhen constructing or copy-constructing a Derived object. It is 109090075Sobrienunspecified whether @samp{Base::operator=} is called more than once when 109190075Sobrienthe implicit copy-assignment for Derived objects is invoked (as it is 109290075Sobrieninside @samp{func} in the example). 109390075Sobrien 109490075Sobrieng++ implements the ``intuitive'' algorithm for copy-assignment: assign all 109590075Sobriendirect bases, then assign all members. In that algorithm, the virtual 109690075Sobrienbase subobject can be encountered many times. In the example, copying 109790075Sobrienproceeds in the following order: @samp{val}, @samp{name} (via 109890075Sobrien@code{strdup}), @samp{bval}, and @samp{name} again. 109990075Sobrien 110090075SobrienIf application code relies on copy-assignment, a user-defined 110190075Sobriencopy-assignment operator removes any uncertainties. With such an 110290075Sobrienoperator, the application can define whether and how the virtual base 110390075Sobriensubobject is assigned. 110490075Sobrien 110590075Sobrien@node Protoize Caveats 110690075Sobrien@section Caveats of using @command{protoize} 110790075Sobrien 110890075SobrienThe conversion programs @command{protoize} and @command{unprotoize} can 110990075Sobriensometimes change a source file in a way that won't work unless you 111090075Sobrienrearrange it. 111190075Sobrien 111290075Sobrien@itemize @bullet 111390075Sobrien@item 111490075Sobrien@command{protoize} can insert references to a type name or type tag before 111590075Sobrienthe definition, or in a file where they are not defined. 111690075Sobrien 111790075SobrienIf this happens, compiler error messages should show you where the new 111890075Sobrienreferences are, so fixing the file by hand is straightforward. 111990075Sobrien 112090075Sobrien@item 112190075SobrienThere are some C constructs which @command{protoize} cannot figure out. 112290075SobrienFor example, it can't determine argument types for declaring a 112390075Sobrienpointer-to-function variable; this you must do by hand. @command{protoize} 112490075Sobrieninserts a comment containing @samp{???} each time it finds such a 112590075Sobrienvariable; so you can find all such variables by searching for this 112690075Sobrienstring. ISO C does not require declaring the argument types of 112790075Sobrienpointer-to-function types. 112890075Sobrien 112990075Sobrien@item 113090075SobrienUsing @command{unprotoize} can easily introduce bugs. If the program 113190075Sobrienrelied on prototypes to bring about conversion of arguments, these 113290075Sobrienconversions will not take place in the program without prototypes. 113390075SobrienOne case in which you can be sure @command{unprotoize} is safe is when 113490075Sobrienyou are removing prototypes that were made with @command{protoize}; if 113590075Sobrienthe program worked before without any prototypes, it will work again 113690075Sobrienwithout them. 113790075Sobrien 113890075Sobrien@opindex Wconversion 113990075SobrienYou can find all the places where this problem might occur by compiling 114090075Sobrienthe program with the @option{-Wconversion} option. It prints a warning 114190075Sobrienwhenever an argument is converted. 114290075Sobrien 114390075Sobrien@item 114490075SobrienBoth conversion programs can be confused if there are macro calls in and 114590075Sobrienaround the text to be converted. In other words, the standard syntax 114690075Sobrienfor a declaration or definition must not result from expanding a macro. 114790075SobrienThis problem is inherent in the design of C and cannot be fixed. If 114890075Sobrienonly a few functions have confusing macro calls, you can easily convert 114990075Sobrienthem manually. 115090075Sobrien 115190075Sobrien@item 115290075Sobrien@command{protoize} cannot get the argument types for a function whose 115390075Sobriendefinition was not actually compiled due to preprocessing conditionals. 115490075SobrienWhen this happens, @command{protoize} changes nothing in regard to such 115590075Sobriena function. @command{protoize} tries to detect such instances and warn 115690075Sobrienabout them. 115790075Sobrien 115890075SobrienYou can generally work around this problem by using @command{protoize} step 115990075Sobrienby step, each time specifying a different set of @option{-D} options for 116090075Sobriencompilation, until all of the functions have been converted. There is 116190075Sobrienno automatic way to verify that you have got them all, however. 116290075Sobrien 116390075Sobrien@item 116490075SobrienConfusion may result if there is an occasion to convert a function 116590075Sobriendeclaration or definition in a region of source code where there is more 116690075Sobrienthan one formal parameter list present. Thus, attempts to convert code 116790075Sobriencontaining multiple (conditionally compiled) versions of a single 116890075Sobrienfunction header (in the same vicinity) may not produce the desired (or 116990075Sobrienexpected) results. 117090075Sobrien 117190075SobrienIf you plan on converting source files which contain such code, it is 117290075Sobrienrecommended that you first make sure that each conditionally compiled 117390075Sobrienregion of source code which contains an alternative function header also 117490075Sobriencontains at least one additional follower token (past the final right 117590075Sobrienparenthesis of the function header). This should circumvent the 117690075Sobrienproblem. 117790075Sobrien 117890075Sobrien@item 117990075Sobrien@command{unprotoize} can become confused when trying to convert a function 118090075Sobriendefinition or declaration which contains a declaration for a 118190075Sobrienpointer-to-function formal argument which has the same name as the 118290075Sobrienfunction being defined or declared. We recommend you avoid such choices 118390075Sobrienof formal parameter names. 118490075Sobrien 118590075Sobrien@item 118690075SobrienYou might also want to correct some of the indentation by hand and break 118790075Sobrienlong lines. (The conversion programs don't write lines longer than 118890075Sobrieneighty characters in any case.) 118990075Sobrien@end itemize 119090075Sobrien 119190075Sobrien@node Non-bugs 119290075Sobrien@section Certain Changes We Don't Want to Make 119390075Sobrien 119490075SobrienThis section lists changes that people frequently request, but which 119590075Sobrienwe do not make because we think GCC is better without them. 119690075Sobrien 119790075Sobrien@itemize @bullet 119890075Sobrien@item 119990075SobrienChecking the number and type of arguments to a function which has an 120090075Sobrienold-fashioned definition and no prototype. 120190075Sobrien 120290075SobrienSuch a feature would work only occasionally---only for calls that appear 120390075Sobrienin the same file as the called function, following the definition. The 120490075Sobrienonly way to check all calls reliably is to add a prototype for the 120590075Sobrienfunction. But adding a prototype eliminates the motivation for this 120690075Sobrienfeature. So the feature is not worthwhile. 120790075Sobrien 120890075Sobrien@item 120990075SobrienWarning about using an expression whose type is signed as a shift count. 121090075Sobrien 121190075SobrienShift count operands are probably signed more often than unsigned. 121290075SobrienWarning about this would cause far more annoyance than good. 121390075Sobrien 121490075Sobrien@item 121590075SobrienWarning about assigning a signed value to an unsigned variable. 121690075Sobrien 121790075SobrienSuch assignments must be very common; warning about them would cause 121890075Sobrienmore annoyance than good. 121990075Sobrien 122090075Sobrien@item 122190075SobrienWarning when a non-void function value is ignored. 122290075Sobrien 122390075SobrienComing as I do from a Lisp background, I balk at the idea that there is 122490075Sobriensomething dangerous about discarding a value. There are functions that 122590075Sobrienreturn values which some callers may find useful; it makes no sense to 122690075Sobrienclutter the program with a cast to @code{void} whenever the value isn't 122790075Sobrienuseful. 122890075Sobrien 122990075Sobrien@item 123090075Sobrien@opindex fshort-enums 123190075SobrienMaking @option{-fshort-enums} the default. 123290075Sobrien 123390075SobrienThis would cause storage layout to be incompatible with most other C 123490075Sobriencompilers. And it doesn't seem very important, given that you can get 123590075Sobrienthe same result in other ways. The case where it matters most is when 123690075Sobrienthe enumeration-valued object is inside a structure, and in that case 123790075Sobrienyou can specify a field width explicitly. 123890075Sobrien 123990075Sobrien@item 124090075SobrienMaking bit-fields unsigned by default on particular machines where ``the 124190075SobrienABI standard'' says to do so. 124290075Sobrien 124390075SobrienThe ISO C standard leaves it up to the implementation whether a bit-field 124490075Sobriendeclared plain @code{int} is signed or not. This in effect creates two 124590075Sobrienalternative dialects of C@. 124690075Sobrien 124790075Sobrien@opindex fsigned-bitfields 124890075Sobrien@opindex funsigned-bitfields 124990075SobrienThe GNU C compiler supports both dialects; you can specify the signed 125090075Sobriendialect with @option{-fsigned-bitfields} and the unsigned dialect with 125190075Sobrien@option{-funsigned-bitfields}. However, this leaves open the question of 125290075Sobrienwhich dialect to use by default. 125390075Sobrien 125490075SobrienCurrently, the preferred dialect makes plain bit-fields signed, because 125590075Sobrienthis is simplest. Since @code{int} is the same as @code{signed int} in 125690075Sobrienevery other context, it is cleanest for them to be the same in bit-fields 125790075Sobrienas well. 125890075Sobrien 125990075SobrienSome computer manufacturers have published Application Binary Interface 126090075Sobrienstandards which specify that plain bit-fields should be unsigned. It is 126190075Sobriena mistake, however, to say anything about this issue in an ABI@. This is 126290075Sobrienbecause the handling of plain bit-fields distinguishes two dialects of C@. 126390075SobrienBoth dialects are meaningful on every type of machine. Whether a 126490075Sobrienparticular object file was compiled using signed bit-fields or unsigned 126590075Sobrienis of no concern to other object files, even if they access the same 126690075Sobrienbit-fields in the same data structures. 126790075Sobrien 126890075SobrienA given program is written in one or the other of these two dialects. 126990075SobrienThe program stands a chance to work on most any machine if it is 127090075Sobriencompiled with the proper dialect. It is unlikely to work at all if 127190075Sobriencompiled with the wrong dialect. 127290075Sobrien 127390075SobrienMany users appreciate the GNU C compiler because it provides an 127490075Sobrienenvironment that is uniform across machines. These users would be 127590075Sobrieninconvenienced if the compiler treated plain bit-fields differently on 127690075Sobriencertain machines. 127790075Sobrien 127890075SobrienOccasionally users write programs intended only for a particular machine 127990075Sobrientype. On these occasions, the users would benefit if the GNU C compiler 128090075Sobrienwere to support by default the same dialect as the other compilers on 128190075Sobrienthat machine. But such applications are rare. And users writing a 128290075Sobrienprogram to run on more than one type of machine cannot possibly benefit 128390075Sobrienfrom this kind of compatibility. 128490075Sobrien 128590075SobrienThis is why GCC does and will treat plain bit-fields in the same 128690075Sobrienfashion on all types of machines (by default). 128790075Sobrien 128890075SobrienThere are some arguments for making bit-fields unsigned by default on all 128990075Sobrienmachines. If, for example, this becomes a universal de facto standard, 129090075Sobrienit would make sense for GCC to go along with it. This is something 129190075Sobriento be considered in the future. 129290075Sobrien 129390075Sobrien(Of course, users strongly concerned about portability should indicate 129490075Sobrienexplicitly in each bit-field whether it is signed or not. In this way, 129590075Sobrienthey write programs which have the same meaning in both C dialects.) 129690075Sobrien 129790075Sobrien@item 129890075Sobrien@opindex ansi 129990075Sobrien@opindex traditional 130090075Sobrien@opindex std 130190075SobrienUndefining @code{__STDC__} when @option{-ansi} is not used. 130290075Sobrien 130390075SobrienCurrently, GCC defines @code{__STDC__} as long as you don't use 130490075Sobrien@option{-traditional}. This provides good results in practice. 130590075Sobrien 130690075SobrienProgrammers normally use conditionals on @code{__STDC__} to ask whether 130790075Sobrienit is safe to use certain features of ISO C, such as function 130890075Sobrienprototypes or ISO token concatenation. Since plain @command{gcc} supports 130990075Sobrienall the features of ISO C, the correct answer to these questions is 131090075Sobrien``yes''. 131190075Sobrien 131290075SobrienSome users try to use @code{__STDC__} to check for the availability of 131390075Sobriencertain library facilities. This is actually incorrect usage in an ISO 131490075SobrienC program, because the ISO C standard says that a conforming 131590075Sobrienfreestanding implementation should define @code{__STDC__} even though it 131690075Sobriendoes not have the library facilities. @samp{gcc -ansi -pedantic} is a 131790075Sobrienconforming freestanding implementation, and it is therefore required to 131890075Sobriendefine @code{__STDC__}, even though it does not come with an ISO C 131990075Sobrienlibrary. 132090075Sobrien 132190075SobrienSometimes people say that defining @code{__STDC__} in a compiler that 132290075Sobriendoes not completely conform to the ISO C standard somehow violates the 132390075Sobrienstandard. This is illogical. The standard is a standard for compilers 132490075Sobrienthat claim to support ISO C, such as @samp{gcc -ansi}---not for other 132590075Sobriencompilers such as plain @command{gcc}. Whatever the ISO C standard says 132690075Sobrienis relevant to the design of plain @command{gcc} without @option{-ansi} only 132790075Sobrienfor pragmatic reasons, not as a requirement. 132890075Sobrien 132990075SobrienGCC normally defines @code{__STDC__} to be 1, and in addition 133090075Sobriendefines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, 133190075Sobrienor a @option{-std} option for strict conformance to some version of ISO C@. 133290075SobrienOn some hosts, system include files use a different convention, where 133390075Sobrien@code{__STDC__} is normally 0, but is 1 if the user specifies strict 133490075Sobrienconformance to the C Standard. GCC follows the host convention when 133590075Sobrienprocessing system include files, but when processing user files it follows 133690075Sobrienthe usual GNU C convention. 133790075Sobrien 133890075Sobrien@item 133990075SobrienUndefining @code{__STDC__} in C++. 134090075Sobrien 134190075SobrienPrograms written to compile with C++-to-C translators get the 134290075Sobrienvalue of @code{__STDC__} that goes with the C compiler that is 134390075Sobriensubsequently used. These programs must test @code{__STDC__} 134490075Sobriento determine what kind of C preprocessor that compiler uses: 134590075Sobrienwhether they should concatenate tokens in the ISO C fashion 134690075Sobrienor in the traditional fashion. 134790075Sobrien 134890075SobrienThese programs work properly with GNU C++ if @code{__STDC__} is defined. 134990075SobrienThey would not work otherwise. 135090075Sobrien 135190075SobrienIn addition, many header files are written to provide prototypes in ISO 135290075SobrienC but not in traditional C@. Many of these header files can work without 135390075Sobrienchange in C++ provided @code{__STDC__} is defined. If @code{__STDC__} 135490075Sobrienis not defined, they will all fail, and will all need to be changed to 135590075Sobrientest explicitly for C++ as well. 135690075Sobrien 135790075Sobrien@item 135890075SobrienDeleting ``empty'' loops. 135990075Sobrien 136090075SobrienHistorically, GCC has not deleted ``empty'' loops under the 136190075Sobrienassumption that the most likely reason you would put one in a program is 136290075Sobriento have a delay, so deleting them will not make real programs run any 136390075Sobrienfaster. 136490075Sobrien 136590075SobrienHowever, the rationale here is that optimization of a nonempty loop 136690075Sobriencannot produce an empty one, which holds for C but is not always the 136790075Sobriencase for C++. 136890075Sobrien 136990075Sobrien@opindex funroll-loops 137090075SobrienMoreover, with @option{-funroll-loops} small ``empty'' loops are already 137190075Sobrienremoved, so the current behavior is both sub-optimal and inconsistent 137290075Sobrienand will change in the future. 137390075Sobrien 137490075Sobrien@item 137590075SobrienMaking side effects happen in the same order as in some other compiler. 137690075Sobrien 137790075Sobrien@cindex side effects, order of evaluation 137890075Sobrien@cindex order of evaluation, side effects 137990075SobrienIt is never safe to depend on the order of evaluation of side effects. 138090075SobrienFor example, a function call like this may very well behave differently 138190075Sobrienfrom one compiler to another: 138290075Sobrien 138390075Sobrien@example 138490075Sobrienvoid func (int, int); 138590075Sobrien 138690075Sobrienint i = 2; 138790075Sobrienfunc (i++, i++); 138890075Sobrien@end example 138990075Sobrien 139090075SobrienThere is no guarantee (in either the C or the C++ standard language 139190075Sobriendefinitions) that the increments will be evaluated in any particular 139290075Sobrienorder. Either increment might happen first. @code{func} might get the 139390075Sobrienarguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. 139490075Sobrien 139590075Sobrien@item 139690075SobrienNot allowing structures with volatile fields in registers. 139790075Sobrien 139890075SobrienStrictly speaking, there is no prohibition in the ISO C standard 139990075Sobrienagainst allowing structures with volatile fields in registers, but 140090075Sobrienit does not seem to make any sense and is probably not what you wanted 140190075Sobriento do. So the compiler will give an error message in this case. 140290075Sobrien 140390075Sobrien@item 140490075SobrienMaking certain warnings into errors by default. 140590075Sobrien 140690075SobrienSome ISO C testsuites report failure when the compiler does not produce 140790075Sobrienan error message for a certain program. 140890075Sobrien 140990075Sobrien@opindex pedantic-errors 141090075SobrienISO C requires a ``diagnostic'' message for certain kinds of invalid 141190075Sobrienprograms, but a warning is defined by GCC to count as a diagnostic. If 141290075SobrienGCC produces a warning but not an error, that is correct ISO C support. 141390075SobrienIf test suites call this ``failure'', they should be run with the GCC 141490075Sobrienoption @option{-pedantic-errors}, which will turn these warnings into 141590075Sobrienerrors. 141690075Sobrien 141790075Sobrien@end itemize 141890075Sobrien 141990075Sobrien@node Warnings and Errors 142090075Sobrien@section Warning Messages and Error Messages 142190075Sobrien 142290075Sobrien@cindex error messages 142390075Sobrien@cindex warnings vs errors 142490075Sobrien@cindex messages, warning and error 142590075SobrienThe GNU compiler can produce two kinds of diagnostics: errors and 142690075Sobrienwarnings. Each kind has a different purpose: 142790075Sobrien 142890075Sobrien@itemize @w{} 142990075Sobrien@item 143090075Sobrien@dfn{Errors} report problems that make it impossible to compile your 143190075Sobrienprogram. GCC reports errors with the source file name and line 143290075Sobriennumber where the problem is apparent. 143390075Sobrien 143490075Sobrien@item 143590075Sobrien@dfn{Warnings} report other unusual conditions in your code that 143690075Sobrien@emph{may} indicate a problem, although compilation can (and does) 143790075Sobrienproceed. Warning messages also report the source file name and line 143890075Sobriennumber, but include the text @samp{warning:} to distinguish them 143990075Sobrienfrom error messages. 144090075Sobrien@end itemize 144190075Sobrien 144290075SobrienWarnings may indicate danger points where you should check to make sure 144390075Sobrienthat your program really does what you intend; or the use of obsolete 144490075Sobrienfeatures; or the use of nonstandard features of GNU C or C++. Many 144590075Sobrienwarnings are issued only if you ask for them, with one of the @option{-W} 144690075Sobrienoptions (for instance, @option{-Wall} requests a variety of useful 144790075Sobrienwarnings). 144890075Sobrien 144990075Sobrien@opindex pedantic 145090075Sobrien@opindex pedantic-errors 145190075SobrienGCC always tries to compile your program if possible; it never 145290075Sobriengratuitously rejects a program whose meaning is clear merely because 145390075Sobrien(for instance) it fails to conform to a standard. In some cases, 145490075Sobrienhowever, the C and C++ standards specify that certain extensions are 145590075Sobrienforbidden, and a diagnostic @emph{must} be issued by a conforming 145690075Sobriencompiler. The @option{-pedantic} option tells GCC to issue warnings in 145790075Sobriensuch cases; @option{-pedantic-errors} says to make them errors instead. 145890075SobrienThis does not mean that @emph{all} non-ISO constructs get warnings 145990075Sobrienor errors. 146090075Sobrien 146190075Sobrien@xref{Warning Options,,Options to Request or Suppress Warnings}, for 146290075Sobrienmore detail on these and related command-line options. 1463