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