trouble.texi revision 146895
190075Sobrien@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 2132718Skan@c 1999, 2000, 2001, 2003, 2004 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 132132718Skannothing that can be done about these problems. 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 166117395SkanOn 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 205117395SkanSPARC 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 222117395SkanThe 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@cindex VAX calling convention 34290075Sobrien@cindex Ultrix calling convention 34390075Sobrien@item 34490075Sobrien@opindex fcall-saved 34590075SobrienOn Ultrix, the Fortran compiler expects registers 2 through 5 to be saved 34690075Sobrienby function calls. However, the C compiler uses conventions compatible 34790075Sobrienwith BSD Unix: registers 2 through 5 may be clobbered by function calls. 34890075Sobrien 34990075SobrienGCC uses the same convention as the Ultrix C compiler. You can use 35090075Sobrienthese options to produce code compatible with the Fortran compiler: 35190075Sobrien 35290075Sobrien@smallexample 35390075Sobrien-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 35490075Sobrien@end smallexample 35590075Sobrien 35690075Sobrien@item 35790075SobrienOn the Alpha, you may get assembler errors about invalid syntax as a 35890075Sobrienresult of floating point constants. This is due to a bug in the C 35990075Sobrienlibrary functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid 36090075Sobrienfloating point numbers, they sometimes print @samp{NaN}. 36190075Sobrien@end itemize 36290075Sobrien 36390075Sobrien@node External Bugs 36490075Sobrien@section Problems Compiling Certain Programs 36590075Sobrien 36690075Sobrien@c prevent bad page break with this line 36790075SobrienCertain programs have problems compiling. 36890075Sobrien 36990075Sobrien@itemize @bullet 37090075Sobrien@item 37190075SobrienParse errors may occur compiling X11 on a Decstation running Ultrix 4.2 37290075Sobrienbecause of problems in DEC's versions of the X11 header files 37390075Sobrien@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding 37490075Sobrien@option{-I/usr/include/mit} to use the MIT versions of the header files, 375117395Skanor fixing the header files by adding this: 37690075Sobrien 377132718Skan@smallexample 37890075Sobrien#ifdef __STDC__ 37990075Sobrien#define NeedFunctionPrototypes 0 38090075Sobrien#endif 381132718Skan@end smallexample 38290075Sobrien 38390075Sobrien@item 38490075SobrienOn various 386 Unix systems derived from System V, including SCO, ISC, 38590075Sobrienand ESIX, you may get error messages about running out of virtual memory 38690075Sobrienwhile compiling certain programs. 38790075Sobrien 38890075SobrienYou can prevent this problem by linking GCC with the GNU malloc 38990075Sobrien(which thus replaces the malloc that comes with the system). GNU malloc 39090075Sobrienis available as a separate package, and also in the file 39190075Sobrien@file{src/gmalloc.c} in the GNU Emacs 19 distribution. 39290075Sobrien 39390075SobrienIf you have installed GNU malloc as a separate library package, use this 39490075Sobrienoption when you relink GCC: 39590075Sobrien 396132718Skan@smallexample 39790075SobrienMALLOC=/usr/local/lib/libgmalloc.a 398132718Skan@end smallexample 39990075Sobrien 40090075SobrienAlternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy 40190075Sobrienthe object file to @file{gmalloc.o} and use this option when you relink 40290075SobrienGCC: 40390075Sobrien 404132718Skan@smallexample 40590075SobrienMALLOC=gmalloc.o 406132718Skan@end smallexample 40790075Sobrien@end itemize 40890075Sobrien 40990075Sobrien@node Incompatibilities 41090075Sobrien@section Incompatibilities of GCC 41190075Sobrien@cindex incompatibilities of GCC 41290075Sobrien@opindex traditional 41390075Sobrien 41490075SobrienThere are several noteworthy incompatibilities between GNU C and K&R 415117395Skan(non-ISO) versions of C@. 41690075Sobrien 41790075Sobrien@itemize @bullet 41890075Sobrien@cindex string constants 41990075Sobrien@cindex read-only strings 42090075Sobrien@cindex shared strings 42190075Sobrien@item 42290075SobrienGCC normally makes string constants read-only. If several 42390075Sobrienidentical-looking string constants are used, GCC stores only one 42490075Sobriencopy of the string. 42590075Sobrien 42690075Sobrien@cindex @code{mktemp}, and constant strings 42790075SobrienOne consequence is that you cannot call @code{mktemp} with a string 42890075Sobrienconstant argument. The function @code{mktemp} always alters the 42990075Sobrienstring its argument points to. 43090075Sobrien 43190075Sobrien@cindex @code{sscanf}, and constant strings 43290075Sobrien@cindex @code{fscanf}, and constant strings 43390075Sobrien@cindex @code{scanf}, and constant strings 43490075SobrienAnother consequence is that @code{sscanf} does not work on some systems 43590075Sobrienwhen passed a string constant as its format control string or input. 43690075SobrienThis is because @code{sscanf} incorrectly tries to write into the string 43790075Sobrienconstant. Likewise @code{fscanf} and @code{scanf}. 43890075Sobrien 43990075Sobrien@opindex fwritable-strings 44090075SobrienThe best solution to these problems is to change the program to use 44190075Sobrien@code{char}-array variables with initialization strings for these 44290075Sobrienpurposes instead of string constants. But if this is not possible, 44390075Sobrienyou can use the @option{-fwritable-strings} flag, which directs GCC 44490075Sobriento handle string constants the same way most C compilers do. 44590075Sobrien 44690075Sobrien@item 44790075Sobrien@code{-2147483648} is positive. 44890075Sobrien 44990075SobrienThis is because 2147483648 cannot fit in the type @code{int}, so 45090075Sobrien(following the ISO C rules) its data type is @code{unsigned long int}. 45190075SobrienNegating this value yields 2147483648 again. 45290075Sobrien 45390075Sobrien@item 45490075SobrienGCC does not substitute macro arguments when they appear inside of 45590075Sobrienstring constants. For example, the following macro in GCC 45690075Sobrien 457132718Skan@smallexample 45890075Sobrien#define foo(a) "a" 459132718Skan@end smallexample 46090075Sobrien 46190075Sobrien@noindent 46290075Sobrienwill produce output @code{"a"} regardless of what the argument @var{a} is. 46390075Sobrien 46490075Sobrien@cindex @code{setjmp} incompatibilities 46590075Sobrien@cindex @code{longjmp} incompatibilities 46690075Sobrien@item 46790075SobrienWhen you use @code{setjmp} and @code{longjmp}, the only automatic 46890075Sobrienvariables guaranteed to remain valid are those declared 46990075Sobrien@code{volatile}. This is a consequence of automatic register 47090075Sobrienallocation. Consider this function: 47190075Sobrien 472132718Skan@smallexample 47390075Sobrienjmp_buf j; 47490075Sobrien 47590075Sobrienfoo () 47690075Sobrien@{ 47790075Sobrien int a, b; 47890075Sobrien 47990075Sobrien a = fun1 (); 48090075Sobrien if (setjmp (j)) 48190075Sobrien return a; 48290075Sobrien 48390075Sobrien a = fun2 (); 48490075Sobrien /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ 48590075Sobrien return a + fun3 (); 48690075Sobrien@} 487132718Skan@end smallexample 48890075Sobrien 48990075SobrienHere @code{a} may or may not be restored to its first value when the 49090075Sobrien@code{longjmp} occurs. If @code{a} is allocated in a register, then 49190075Sobrienits first value is restored; otherwise, it keeps the last value stored 49290075Sobrienin it. 49390075Sobrien 49490075Sobrien@opindex W 49590075SobrienIf you use the @option{-W} option with the @option{-O} option, you will 49690075Sobrienget a warning when GCC thinks such a problem might be possible. 49790075Sobrien 49890075Sobrien@item 49990075SobrienPrograms that use preprocessing directives in the middle of macro 50090075Sobrienarguments do not work with GCC@. For example, a program like this 50190075Sobrienwill not work: 50290075Sobrien 503132718Skan@smallexample 50490075Sobrien@group 50590075Sobrienfoobar ( 50690075Sobrien#define luser 50790075Sobrien hack) 50890075Sobrien@end group 509132718Skan@end smallexample 51090075Sobrien 511117395SkanISO C does not permit such a construct. 51290075Sobrien 51390075Sobrien@item 51490075SobrienK&R compilers allow comments to cross over an inclusion boundary 515132718Skan(i.e.@: started in an include file and ended in the including file). 51690075Sobrien 51790075Sobrien@cindex external declaration scope 51890075Sobrien@cindex scope of external declarations 51990075Sobrien@cindex declaration scope 52090075Sobrien@item 52190075SobrienDeclarations of external variables and functions within a block apply 52290075Sobrienonly to the block containing the declaration. In other words, they 52390075Sobrienhave the same scope as any other declaration in the same place. 52490075Sobrien 52590075SobrienIn some other C compilers, a @code{extern} declaration affects all the 52690075Sobrienrest of the file even if it happens within a block. 52790075Sobrien 52890075Sobrien@item 52990075SobrienIn traditional C, you can combine @code{long}, etc., with a typedef name, 53090075Sobrienas shown here: 53190075Sobrien 532132718Skan@smallexample 53390075Sobrientypedef int foo; 53490075Sobrientypedef long foo bar; 535132718Skan@end smallexample 53690075Sobrien 53790075SobrienIn ISO C, this is not allowed: @code{long} and other type modifiers 538117395Skanrequire an explicit @code{int}. 53990075Sobrien 54090075Sobrien@cindex typedef names as function parameters 54190075Sobrien@item 542117395SkanPCC allows typedef names to be used as function parameters. 54390075Sobrien 54490075Sobrien@item 545117395SkanTraditional C allows the following erroneous pair of declarations to 546117395Skanappear together in a given scope: 54790075Sobrien 548132718Skan@smallexample 54990075Sobrientypedef int foo; 55090075Sobrientypedef foo foo; 551132718Skan@end smallexample 55290075Sobrien 55390075Sobrien@item 554117395SkanGCC treats all characters of identifiers as significant. According to 555117395SkanK&R-1 (2.2), ``No more than the first eight characters are significant, 556117395Skanalthough more may be used.''. Also according to K&R-1 (2.2), ``An 557117395Skanidentifier is a sequence of letters and digits; the first character must 558117395Skanbe a letter. The underscore _ counts as a letter.'', but GCC also 559117395Skanallows dollar signs in identifiers. 56090075Sobrien 56190075Sobrien@cindex whitespace 56290075Sobrien@item 56390075SobrienPCC allows whitespace in the middle of compound assignment operators 56490075Sobriensuch as @samp{+=}. GCC, following the ISO standard, does not 565117395Skanallow this. 56690075Sobrien 56790075Sobrien@cindex apostrophes 56890075Sobrien@cindex ' 56990075Sobrien@item 57090075SobrienGCC complains about unterminated character constants inside of 57190075Sobrienpreprocessing conditionals that fail. Some programs have English 57290075Sobriencomments enclosed in conditionals that are guaranteed to fail; if these 57390075Sobriencomments contain apostrophes, GCC will probably report an error. For 57490075Sobrienexample, this code would produce an error: 57590075Sobrien 576132718Skan@smallexample 57790075Sobrien#if 0 57890075SobrienYou can't expect this to work. 57990075Sobrien#endif 580132718Skan@end smallexample 58190075Sobrien 58290075SobrienThe best solution to such a problem is to put the text into an actual 583117395SkanC comment delimited by @samp{/*@dots{}*/}. 58490075Sobrien 58590075Sobrien@item 58690075SobrienMany user programs contain the declaration @samp{long time ();}. In the 58790075Sobrienpast, the system header files on many systems did not actually declare 58890075Sobrien@code{time}, so it did not matter what type your program declared it to 58990075Sobrienreturn. But in systems with ISO C headers, @code{time} is declared to 59090075Sobrienreturn @code{time_t}, and if that is not the same as @code{long}, then 59190075Sobrien@samp{long time ();} is erroneous. 59290075Sobrien 59390075SobrienThe solution is to change your program to use appropriate system headers 59490075Sobrien(@code{<time.h>} on systems with ISO C headers) and not to declare 59590075Sobrien@code{time} if the system header files declare it, or failing that to 59690075Sobrienuse @code{time_t} as the return type of @code{time}. 59790075Sobrien 59890075Sobrien@cindex @code{float} as function value type 59990075Sobrien@item 60090075SobrienWhen compiling functions that return @code{float}, PCC converts it to 60190075Sobriena double. GCC actually returns a @code{float}. If you are concerned 60290075Sobrienwith PCC compatibility, you should declare your functions to return 60390075Sobrien@code{double}; you might as well say what you mean. 60490075Sobrien 60590075Sobrien@cindex structures 60690075Sobrien@cindex unions 60790075Sobrien@item 60890075SobrienWhen compiling functions that return structures or unions, GCC 60990075Sobrienoutput code normally uses a method different from that used on most 61090075Sobrienversions of Unix. As a result, code compiled with GCC cannot call 61190075Sobriena structure-returning function compiled with PCC, and vice versa. 61290075Sobrien 61390075SobrienThe method used by GCC is as follows: a structure or union which is 61490075Sobrien1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union 61590075Sobrienwith any other size is stored into an address supplied by the caller 61690075Sobrien(usually in a special, fixed register, but on some machines it is passed 617132718Skanon the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX} 618132718Skantells GCC where to pass this address. 61990075Sobrien 62090075SobrienBy contrast, PCC on most target machines returns structures and unions 62190075Sobrienof any size by copying the data into an area of static storage, and then 62290075Sobrienreturning the address of that storage as if it were a pointer value. 62390075SobrienThe caller must copy the data from that memory area to the place where 62490075Sobrienthe value is wanted. GCC does not use this method because it is 62590075Sobrienslower and nonreentrant. 62690075Sobrien 62790075SobrienOn some newer machines, PCC uses a reentrant convention for all 62890075Sobrienstructure and union returning. GCC on most of these machines uses a 62990075Sobriencompatible convention when returning structures and unions in memory, 63090075Sobrienbut still returns small structures and unions in registers. 63190075Sobrien 63290075Sobrien@opindex fpcc-struct-return 63390075SobrienYou can tell GCC to use a compatible convention for all structure and 63490075Sobrienunion returning with the option @option{-fpcc-struct-return}. 63590075Sobrien 63690075Sobrien@cindex preprocessing tokens 63790075Sobrien@cindex preprocessing numbers 63890075Sobrien@item 63990075SobrienGCC complains about program fragments such as @samp{0x74ae-0x4000} 64090075Sobrienwhich appear to be two hexadecimal constants separated by the minus 64190075Sobrienoperator. Actually, this string is a single @dfn{preprocessing token}. 64290075SobrienEach such token must correspond to one token in C@. Since this does not, 64390075SobrienGCC prints an error message. Although it may appear obvious that what 64490075Sobrienis meant is an operator and two values, the ISO C standard specifically 64590075Sobrienrequires that this be treated as erroneous. 64690075Sobrien 64790075SobrienA @dfn{preprocessing token} is a @dfn{preprocessing number} if it 64890075Sobrienbegins with a digit and is followed by letters, underscores, digits, 64990075Sobrienperiods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, 65090075Sobrien@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89 65190075Sobrienmode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot 65290075Sobrienappear in preprocessing numbers.) 65390075Sobrien 65490075SobrienTo make the above program fragment valid, place whitespace in front of 65590075Sobrienthe minus sign. This whitespace will end the preprocessing number. 65690075Sobrien@end itemize 65790075Sobrien 65890075Sobrien@node Fixed Headers 65990075Sobrien@section Fixed Header Files 66090075Sobrien 66190075SobrienGCC needs to install corrected versions of some system header files. 66290075SobrienThis is because most target systems have some header files that won't 66390075Sobrienwork with GCC unless they are changed. Some have bugs, some are 66490075Sobrienincompatible with ISO C, and some depend on special features of other 66590075Sobriencompilers. 66690075Sobrien 66790075SobrienInstalling GCC automatically creates and installs the fixed header 66890075Sobrienfiles, by running a program called @code{fixincludes} (or for certain 66990075Sobrientargets an alternative such as @code{fixinc.svr4}). Normally, you 67090075Sobriendon't need to pay attention to this. But there are cases where it 67190075Sobriendoesn't do the right thing automatically. 67290075Sobrien 67390075Sobrien@itemize @bullet 67490075Sobrien@item 67590075SobrienIf you update the system's header files, such as by installing a new 67690075Sobriensystem version, the fixed header files of GCC are not automatically 67790075Sobrienupdated. The easiest way to update them is to reinstall GCC@. (If 67890075Sobrienyou want to be clever, look in the makefile and you can find a 67990075Sobrienshortcut.) 68090075Sobrien 68190075Sobrien@item 68290075SobrienOn some systems, in particular SunOS 4, header file directories contain 68390075Sobrienmachine-specific symbolic links in certain places. This makes it 68490075Sobrienpossible to share most of the header files among hosts running the 68590075Sobriensame version of SunOS 4 on different machine models. 68690075Sobrien 68790075SobrienThe programs that fix the header files do not understand this special 68890075Sobrienway of using symbolic links; therefore, the directory of fixed header 68990075Sobrienfiles is good only for the machine model used to build it. 69090075Sobrien 69190075SobrienIn SunOS 4, only programs that look inside the kernel will notice the 69290075Sobriendifference between machine models. Therefore, for most purposes, you 69390075Sobrienneed not be concerned about this. 69490075Sobrien 69590075SobrienIt is possible to make separate sets of fixed header files for the 69690075Sobriendifferent machine models, and arrange a structure of symbolic links so 69790075Sobrienas to use the proper set, but you'll have to do this by hand. 69890075Sobrien 69990075Sobrien@item 70090075SobrienOn Lynxos, GCC by default does not fix the header files. This is 70190075Sobrienbecause bugs in the shell cause the @code{fixincludes} script to fail. 70290075Sobrien 70390075SobrienThis means you will encounter problems due to bugs in the system header 70490075Sobrienfiles. It may be no comfort that they aren't GCC's fault, but it 70590075Sobriendoes mean that there's nothing for us to do about them. 70690075Sobrien@end itemize 70790075Sobrien 70890075Sobrien@node Standard Libraries 70990075Sobrien@section Standard Libraries 71090075Sobrien 71190075Sobrien@opindex Wall 71290075SobrienGCC by itself attempts to be a conforming freestanding implementation. 71390075Sobrien@xref{Standards,,Language Standards Supported by GCC}, for details of 71490075Sobrienwhat this means. Beyond the library facilities required of such an 71590075Sobrienimplementation, the rest of the C library is supplied by the vendor of 71690075Sobrienthe operating system. If that C library doesn't conform to the C 71790075Sobrienstandards, then your programs might get warnings (especially when using 71890075Sobrien@option{-Wall}) that you don't expect. 71990075Sobrien 72090075SobrienFor example, the @code{sprintf} function on SunOS 4.1.3 returns 72190075Sobrien@code{char *} while the C standard says that @code{sprintf} returns an 72290075Sobrien@code{int}. The @code{fixincludes} program could make the prototype for 72390075Sobrienthis function match the Standard, but that would be wrong, since the 72490075Sobrienfunction will still return @code{char *}. 72590075Sobrien 72690075SobrienIf you need a Standard compliant library, then you need to find one, as 72790075SobrienGCC does not provide one. The GNU C library (called @code{glibc}) 72890075Sobrienprovides ISO C, POSIX, BSD, SystemV and X/Open compatibility for 72990075SobrienGNU/Linux and HURD-based GNU systems; no recent version of it supports 73090075Sobrienother systems, though some very old versions did. Version 2.2 of the 73190075SobrienGNU C library includes nearly complete C99 support. You could also ask 73290075Sobrienyour operating system vendor if newer libraries are available. 73390075Sobrien 73490075Sobrien@node Disappointments 73590075Sobrien@section Disappointments and Misunderstandings 73690075Sobrien 73790075SobrienThese problems are perhaps regrettable, but we don't know any practical 73890075Sobrienway around them. 73990075Sobrien 74090075Sobrien@itemize @bullet 74190075Sobrien@item 74290075SobrienCertain local variables aren't recognized by debuggers when you compile 74390075Sobrienwith optimization. 74490075Sobrien 74590075SobrienThis occurs because sometimes GCC optimizes the variable out of 74690075Sobrienexistence. There is no way to tell the debugger how to compute the 74790075Sobrienvalue such a variable ``would have had'', and it is not clear that would 74890075Sobrienbe desirable anyway. So GCC simply does not mention the eliminated 74990075Sobrienvariable when it writes debugging information. 75090075Sobrien 75190075SobrienYou have to expect a certain amount of disagreement between the 75290075Sobrienexecutable and your source code, when you use optimization. 75390075Sobrien 75490075Sobrien@cindex conflicting types 75590075Sobrien@cindex scope of declaration 75690075Sobrien@item 75790075SobrienUsers often think it is a bug when GCC reports an error for code 75890075Sobrienlike this: 75990075Sobrien 760132718Skan@smallexample 76190075Sobrienint foo (struct mumble *); 76290075Sobrien 76390075Sobrienstruct mumble @{ @dots{} @}; 76490075Sobrien 76590075Sobrienint foo (struct mumble *x) 76690075Sobrien@{ @dots{} @} 767132718Skan@end smallexample 76890075Sobrien 76990075SobrienThis code really is erroneous, because the scope of @code{struct 77090075Sobrienmumble} in the prototype is limited to the argument list containing it. 77190075SobrienIt does not refer to the @code{struct mumble} defined with file scope 77290075Sobrienimmediately below---they are two unrelated types with similar names in 77390075Sobriendifferent scopes. 77490075Sobrien 77590075SobrienBut in the definition of @code{foo}, the file-scope type is used 77690075Sobrienbecause that is available to be inherited. Thus, the definition and 77790075Sobrienthe prototype do not match, and you get an error. 77890075Sobrien 77990075SobrienThis behavior may seem silly, but it's what the ISO standard specifies. 78090075SobrienIt is easy enough for you to make your code work by moving the 78190075Sobriendefinition of @code{struct mumble} above the prototype. It's not worth 78290075Sobrienbeing incompatible with ISO C just to avoid an error for the example 78390075Sobrienshown above. 78490075Sobrien 78590075Sobrien@item 78690075SobrienAccesses to bit-fields even in volatile objects works by accessing larger 78790075Sobrienobjects, such as a byte or a word. You cannot rely on what size of 78890075Sobrienobject is accessed in order to read or write the bit-field; it may even 78990075Sobrienvary for a given bit-field according to the precise usage. 79090075Sobrien 79190075SobrienIf you care about controlling the amount of memory that is accessed, use 79290075Sobrienvolatile but do not use bit-fields. 79390075Sobrien 79490075Sobrien@item 79590075SobrienGCC comes with shell scripts to fix certain known problems in system 79690075Sobrienheader files. They install corrected copies of various header files in 79790075Sobriena special directory where only GCC will normally look for them. The 79890075Sobrienscripts adapt to various systems by searching all the system header 79990075Sobrienfiles for the problem cases that we know about. 80090075Sobrien 80190075SobrienIf new system header files are installed, nothing automatically arranges 80290075Sobriento update the corrected header files. You will have to reinstall GCC 80390075Sobriento fix the new header files. More specifically, go to the build 80490075Sobriendirectory and delete the files @file{stmp-fixinc} and 80590075Sobrien@file{stmp-headers}, and the subdirectory @code{include}; then do 80690075Sobrien@samp{make install} again. 80790075Sobrien 80890075Sobrien@item 80990075Sobrien@cindex floating point precision 81090075SobrienOn 68000 and x86 systems, for instance, you can get paradoxical results 81190075Sobrienif you test the precise values of floating point numbers. For example, 81290075Sobrienyou can find that a floating point value which is not a NaN is not equal 81390075Sobriento itself. This results from the fact that the floating point registers 81490075Sobrienhold a few more bits of precision than fit in a @code{double} in memory. 81590075SobrienCompiled code moves values between memory and floating point registers 81690075Sobrienat its convenience, and moving them into memory truncates them. 81790075Sobrien 81890075Sobrien@opindex ffloat-store 81990075SobrienYou can partially avoid this problem by using the @option{-ffloat-store} 82090075Sobrienoption (@pxref{Optimize Options}). 82190075Sobrien 82290075Sobrien@item 82390075SobrienOn AIX and other platforms without weak symbol support, templates 82490075Sobrienneed to be instantiated explicitly and symbols for static members 82590075Sobrienof templates will not be generated. 826117395Skan 827117395Skan@item 828117395SkanOn AIX, GCC scans object files and library archives for static 829117395Skanconstructors and destructors when linking an application before the 830117395Skanlinker prunes unreferenced symbols. This is necessary to prevent the 831117395SkanAIX linker from mistakenly assuming that static constructor or 832117395Skandestructor are unused and removing them before the scanning can occur. 833117395SkanAll static constructors and destructors found will be referenced even 834117395Skanthough the modules in which they occur may not be used by the program. 835117395SkanThis may lead to both increased executable size and unexpected symbol 836117395Skanreferences. 83790075Sobrien@end itemize 83890075Sobrien 83990075Sobrien@node C++ Misunderstandings 84090075Sobrien@section Common Misunderstandings with GNU C++ 84190075Sobrien 84290075Sobrien@cindex misunderstandings in C++ 84390075Sobrien@cindex surprises in C++ 84490075Sobrien@cindex C++ misunderstandings 84590075SobrienC++ is a complex language and an evolving one, and its standard 84690075Sobriendefinition (the ISO C++ standard) was only recently completed. As a 84790075Sobrienresult, your C++ compiler may occasionally surprise you, even when its 84890075Sobrienbehavior is correct. This section discusses some areas that frequently 84990075Sobriengive rise to questions of this sort. 85090075Sobrien 85190075Sobrien@menu 85290075Sobrien* Static Definitions:: Static member declarations are not definitions 853132718Skan* Name lookup:: Name lookup, templates, and accessing members of base classes 85490075Sobrien* Temporaries:: Temporaries may vanish before you expect 85590075Sobrien* Copy Assignment:: Copy Assignment operators copy virtual bases twice 85690075Sobrien@end menu 85790075Sobrien 85890075Sobrien@node Static Definitions 85990075Sobrien@subsection Declare @emph{and} Define Static Members 86090075Sobrien 86190075Sobrien@cindex C++ static data, declaring and defining 86290075Sobrien@cindex static data in C++, declaring and defining 86390075Sobrien@cindex declaring static data in C++ 86490075Sobrien@cindex defining static data in C++ 86590075SobrienWhen a class has static data members, it is not enough to @emph{declare} 86690075Sobrienthe static member; you must also @emph{define} it. For example: 86790075Sobrien 868132718Skan@smallexample 86990075Sobrienclass Foo 87090075Sobrien@{ 87190075Sobrien @dots{} 87290075Sobrien void method(); 87390075Sobrien static int bar; 87490075Sobrien@}; 875132718Skan@end smallexample 87690075Sobrien 87790075SobrienThis declaration only establishes that the class @code{Foo} has an 87890075Sobrien@code{int} named @code{Foo::bar}, and a member function named 87990075Sobrien@code{Foo::method}. But you still need to define @emph{both} 88090075Sobrien@code{method} and @code{bar} elsewhere. According to the ISO 88190075Sobrienstandard, you must supply an initializer in one (and only one) source 88290075Sobrienfile, such as: 88390075Sobrien 884132718Skan@smallexample 88590075Sobrienint Foo::bar = 0; 886132718Skan@end smallexample 88790075Sobrien 88890075SobrienOther C++ compilers may not correctly implement the standard behavior. 889117395SkanAs a result, when you switch to @command{g++} from one of these compilers, 89090075Sobrienyou may discover that a program that appeared to work correctly in fact 891117395Skandoes not conform to the standard: @command{g++} reports as undefined 89290075Sobriensymbols any static data members that lack definitions. 89390075Sobrien 894132718Skan 895132718Skan@node Name lookup 896132718Skan@subsection Name lookup, templates, and accessing members of base classes 897132718Skan 898132718Skan@cindex base class members 899132718Skan@cindex two-stage name lookup 900132718Skan@cindex dependent name lookup 901132718Skan 902132718SkanThe C++ standard prescribes that all names that are not dependent on 903132718Skantemplate parameters are bound to their present definitions when parsing 904132718Skana template function or class.@footnote{The C++ standard just uses the 905132718Skanterm ``dependent'' for names that depend on the type or value of 906132718Skantemplate parameters. This shorter term will also be used in the rest of 907132718Skanthis section.} Only names that are dependent are looked up at the point 908132718Skanof instantiation. For example, consider 909132718Skan 910132718Skan@smallexample 911132718Skan void foo(double); 912132718Skan 913132718Skan struct A @{ 914132718Skan template <typename T> 915132718Skan void f () @{ 916132718Skan foo (1); // 1 917132718Skan int i = N; // 2 918132718Skan T t; 919132718Skan t.bar(); // 3 920132718Skan foo (t); // 4 921132718Skan @} 922132718Skan 923132718Skan static const int N; 924132718Skan @}; 925132718Skan@end smallexample 926132718Skan 927132718SkanHere, the names @code{foo} and @code{N} appear in a context that does 928132718Skannot depend on the type of @code{T}. The compiler will thus require that 929132718Skanthey are defined in the context of use in the template, not only before 930132718Skanthe point of instantiation, and will here use @code{::foo(double)} and 931132718Skan@code{A::N}, respectively. In particular, it will convert the integer 932132718Skanvalue to a @code{double} when passing it to @code{::foo(double)}. 933132718Skan 934132718SkanConversely, @code{bar} and the call to @code{foo} in the fourth marked 935132718Skanline are used in contexts that do depend on the type of @code{T}, so 936132718Skanthey are only looked up at the point of instantiation, and you can 937132718Skanprovide declarations for them after declaring the template, but before 938132718Skaninstantiating it. In particular, if you instantiate @code{A::f<int>}, 939132718Skanthe last line will call an overloaded @code{::foo(int)} if one was 940132718Skanprovided, even if after the declaration of @code{struct A}. 941132718Skan 942132718SkanThis distinction between lookup of dependent and non-dependent names is 943132718Skancalled two-stage (or dependent) name lookup. G++ implements it 944132718Skansince version 3.4. 945132718Skan 946132718SkanTwo-stage name lookup sometimes leads to situations with behavior 947132718Skandifferent from non-template codes. The most common is probably this: 948132718Skan 949132718Skan@smallexample 950132718Skan template <typename T> struct Base @{ 951132718Skan int i; 952132718Skan @}; 953132718Skan 954132718Skan template <typename T> struct Derived : public Base<T> @{ 955132718Skan int get_i() @{ return i; @} 956132718Skan @}; 957132718Skan@end smallexample 958132718Skan 959132718SkanIn @code{get_i()}, @code{i} is not used in a dependent context, so the 960132718Skancompiler will look for a name declared at the enclosing namespace scope 961132718Skan(which is the global scope here). It will not look into the base class, 962132718Skansince that is dependent and you may declare specializations of 963132718Skan@code{Base} even after declaring @code{Derived}, so the compiler can't 964132718Skanreally know what @code{i} would refer to. If there is no global 965132718Skanvariable @code{i}, then you will get an error message. 966132718Skan 967132718SkanIn order to make it clear that you want the member of the base class, 968132718Skanyou need to defer lookup until instantiation time, at which the base 969132718Skanclass is known. For this, you need to access @code{i} in a dependent 970132718Skancontext, by either using @code{this->i} (remember that @code{this} is of 971132718Skantype @code{Derived<T>*}, so is obviously dependent), or using 972132718Skan@code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought 973132718Skaninto scope by a @code{using}-declaration. 974132718Skan 975132718SkanAnother, similar example involves calling member functions of a base 976132718Skanclass: 977132718Skan 978132718Skan@smallexample 979132718Skan template <typename T> struct Base @{ 980132718Skan int f(); 981132718Skan @}; 982132718Skan 983132718Skan template <typename T> struct Derived : Base<T> @{ 984132718Skan int g() @{ return f(); @}; 985132718Skan @}; 986132718Skan@end smallexample 987132718Skan 988132718SkanAgain, the call to @code{f()} is not dependent on template arguments 989132718Skan(there are no arguments that depend on the type @code{T}, and it is also 990132718Skannot otherwise specified that the call should be in a dependent context). 991132718SkanThus a global declaration of such a function must be available, since 992132718Skanthe one in the base class is not visible until instantiation time. The 993132718Skancompiler will consequently produce the following error message: 994132718Skan 995132718Skan@smallexample 996132718Skan x.cc: In member function `int Derived<T>::g()': 997132718Skan x.cc:6: error: there are no arguments to `f' that depend on a template 998132718Skan parameter, so a declaration of `f' must be available 999132718Skan x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but 1000132718Skan allowing the use of an undeclared name is deprecated) 1001132718Skan@end smallexample 1002132718Skan 1003132718SkanTo make the code valid either use @code{this->f()}, or 1004132718Skan@code{Base<T>::f()}. Using the @code{-fpermissive} flag will also let 1005132718Skanthe compiler accept the code, by marking all function calls for which no 1006132718Skandeclaration is visible at the time of definition of the template for 1007132718Skanlater lookup at instantiation time, as if it were a dependent call. 1008132718SkanWe do not recommend using @code{-fpermissive} to work around invalid 1009132718Skancode, and it will also only catch cases where functions in base classes 1010132718Skanare called, not where variables in base classes are used (as in the 1011132718Skanexample above). 1012132718Skan 1013132718SkanNote that some compilers (including G++ versions prior to 3.4) get these 1014132718Skanexamples wrong and accept above code without an error. Those compilers 1015132718Skando not implement two-stage name lookup correctly. 1016132718Skan 1017132718Skan 101890075Sobrien@node Temporaries 101990075Sobrien@subsection Temporaries May Vanish Before You Expect 102090075Sobrien 102190075Sobrien@cindex temporaries, lifetime of 102290075Sobrien@cindex portions of temporary objects, pointers to 102390075SobrienIt is dangerous to use pointers or references to @emph{portions} of a 102490075Sobrientemporary object. The compiler may very well delete the object before 102590075Sobrienyou expect it to, leaving a pointer to garbage. The most common place 102690075Sobrienwhere this problem crops up is in classes like string classes, 102790075Sobrienespecially ones that define a conversion function to type @code{char *} 102890075Sobrienor @code{const char *}---which is one reason why the standard 102990075Sobrien@code{string} class requires you to call the @code{c_str} member 103090075Sobrienfunction. However, any class that returns a pointer to some internal 103190075Sobrienstructure is potentially subject to this problem. 103290075Sobrien 103390075SobrienFor example, a program may use a function @code{strfunc} that returns 103490075Sobrien@code{string} objects, and another function @code{charfunc} that 103590075Sobrienoperates on pointers to @code{char}: 103690075Sobrien 1037132718Skan@smallexample 103890075Sobrienstring strfunc (); 103990075Sobrienvoid charfunc (const char *); 104090075Sobrien 104190075Sobrienvoid 104290075Sobrienf () 104390075Sobrien@{ 104490075Sobrien const char *p = strfunc().c_str(); 104590075Sobrien @dots{} 104690075Sobrien charfunc (p); 104790075Sobrien @dots{} 104890075Sobrien charfunc (p); 104990075Sobrien@} 1050132718Skan@end smallexample 105190075Sobrien 105290075Sobrien@noindent 105390075SobrienIn this situation, it may seem reasonable to save a pointer to the C 105490075Sobrienstring returned by the @code{c_str} member function and use that rather 105590075Sobrienthan call @code{c_str} repeatedly. However, the temporary string 105690075Sobriencreated by the call to @code{strfunc} is destroyed after @code{p} is 105790075Sobrieninitialized, at which point @code{p} is left pointing to freed memory. 105890075Sobrien 105990075SobrienCode like this may run successfully under some other compilers, 106090075Sobrienparticularly obsolete cfront-based compilers that delete temporaries 106190075Sobrienalong with normal local variables. However, the GNU C++ behavior is 106290075Sobrienstandard-conforming, so if your program depends on late destruction of 106390075Sobrientemporaries it is not portable. 106490075Sobrien 106590075SobrienThe safe way to write such code is to give the temporary a name, which 106690075Sobrienforces it to remain until the end of the scope of the name. For 106790075Sobrienexample: 106890075Sobrien 1069132718Skan@smallexample 1070146895Skanconst string& tmp = strfunc (); 107190075Sobriencharfunc (tmp.c_str ()); 1072132718Skan@end smallexample 107390075Sobrien 107490075Sobrien@node Copy Assignment 107590075Sobrien@subsection Implicit Copy-Assignment for Virtual Bases 107690075Sobrien 107790075SobrienWhen a base class is virtual, only one subobject of the base class 107890075Sobrienbelongs to each full object. Also, the constructors and destructors are 107990075Sobrieninvoked only once, and called from the most-derived class. However, such 108090075Sobrienobjects behave unspecified when being assigned. For example: 108190075Sobrien 1082132718Skan@smallexample 108390075Sobrienstruct Base@{ 108490075Sobrien char *name; 108590075Sobrien Base(char *n) : name(strdup(n))@{@} 108690075Sobrien Base& operator= (const Base& other)@{ 108790075Sobrien free (name); 108890075Sobrien name = strdup (other.name); 108990075Sobrien @} 109090075Sobrien@}; 109190075Sobrien 109290075Sobrienstruct A:virtual Base@{ 109390075Sobrien int val; 109490075Sobrien A():Base("A")@{@} 109590075Sobrien@}; 109690075Sobrien 109790075Sobrienstruct B:virtual Base@{ 109890075Sobrien int bval; 109990075Sobrien B():Base("B")@{@} 110090075Sobrien@}; 110190075Sobrien 110290075Sobrienstruct Derived:public A, public B@{ 110390075Sobrien Derived():Base("Derived")@{@} 110490075Sobrien@}; 110590075Sobrien 110690075Sobrienvoid func(Derived &d1, Derived &d2) 110790075Sobrien@{ 110890075Sobrien d1 = d2; 110990075Sobrien@} 1110132718Skan@end smallexample 111190075Sobrien 111290075SobrienThe C++ standard specifies that @samp{Base::Base} is only called once 111390075Sobrienwhen constructing or copy-constructing a Derived object. It is 111490075Sobrienunspecified whether @samp{Base::operator=} is called more than once when 111590075Sobrienthe implicit copy-assignment for Derived objects is invoked (as it is 111690075Sobrieninside @samp{func} in the example). 111790075Sobrien 1118132718SkanG++ implements the ``intuitive'' algorithm for copy-assignment: assign all 111990075Sobriendirect bases, then assign all members. In that algorithm, the virtual 1120119256Skanbase subobject can be encountered more than once. In the example, copying 112190075Sobrienproceeds in the following order: @samp{val}, @samp{name} (via 112290075Sobrien@code{strdup}), @samp{bval}, and @samp{name} again. 112390075Sobrien 112490075SobrienIf application code relies on copy-assignment, a user-defined 112590075Sobriencopy-assignment operator removes any uncertainties. With such an 112690075Sobrienoperator, the application can define whether and how the virtual base 112790075Sobriensubobject is assigned. 112890075Sobrien 112990075Sobrien@node Protoize Caveats 113090075Sobrien@section Caveats of using @command{protoize} 113190075Sobrien 113290075SobrienThe conversion programs @command{protoize} and @command{unprotoize} can 113390075Sobriensometimes change a source file in a way that won't work unless you 113490075Sobrienrearrange it. 113590075Sobrien 113690075Sobrien@itemize @bullet 113790075Sobrien@item 113890075Sobrien@command{protoize} can insert references to a type name or type tag before 113990075Sobrienthe definition, or in a file where they are not defined. 114090075Sobrien 114190075SobrienIf this happens, compiler error messages should show you where the new 114290075Sobrienreferences are, so fixing the file by hand is straightforward. 114390075Sobrien 114490075Sobrien@item 114590075SobrienThere are some C constructs which @command{protoize} cannot figure out. 114690075SobrienFor example, it can't determine argument types for declaring a 114790075Sobrienpointer-to-function variable; this you must do by hand. @command{protoize} 114890075Sobrieninserts a comment containing @samp{???} each time it finds such a 114990075Sobrienvariable; so you can find all such variables by searching for this 115090075Sobrienstring. ISO C does not require declaring the argument types of 115190075Sobrienpointer-to-function types. 115290075Sobrien 115390075Sobrien@item 115490075SobrienUsing @command{unprotoize} can easily introduce bugs. If the program 115590075Sobrienrelied on prototypes to bring about conversion of arguments, these 115690075Sobrienconversions will not take place in the program without prototypes. 115790075SobrienOne case in which you can be sure @command{unprotoize} is safe is when 115890075Sobrienyou are removing prototypes that were made with @command{protoize}; if 115990075Sobrienthe program worked before without any prototypes, it will work again 116090075Sobrienwithout them. 116190075Sobrien 116290075Sobrien@opindex Wconversion 116390075SobrienYou can find all the places where this problem might occur by compiling 116490075Sobrienthe program with the @option{-Wconversion} option. It prints a warning 116590075Sobrienwhenever an argument is converted. 116690075Sobrien 116790075Sobrien@item 116890075SobrienBoth conversion programs can be confused if there are macro calls in and 116990075Sobrienaround the text to be converted. In other words, the standard syntax 117090075Sobrienfor a declaration or definition must not result from expanding a macro. 117190075SobrienThis problem is inherent in the design of C and cannot be fixed. If 117290075Sobrienonly a few functions have confusing macro calls, you can easily convert 117390075Sobrienthem manually. 117490075Sobrien 117590075Sobrien@item 117690075Sobrien@command{protoize} cannot get the argument types for a function whose 117790075Sobriendefinition was not actually compiled due to preprocessing conditionals. 117890075SobrienWhen this happens, @command{protoize} changes nothing in regard to such 117990075Sobriena function. @command{protoize} tries to detect such instances and warn 118090075Sobrienabout them. 118190075Sobrien 118290075SobrienYou can generally work around this problem by using @command{protoize} step 118390075Sobrienby step, each time specifying a different set of @option{-D} options for 118490075Sobriencompilation, until all of the functions have been converted. There is 118590075Sobrienno automatic way to verify that you have got them all, however. 118690075Sobrien 118790075Sobrien@item 118890075SobrienConfusion may result if there is an occasion to convert a function 118990075Sobriendeclaration or definition in a region of source code where there is more 119090075Sobrienthan one formal parameter list present. Thus, attempts to convert code 119190075Sobriencontaining multiple (conditionally compiled) versions of a single 119290075Sobrienfunction header (in the same vicinity) may not produce the desired (or 119390075Sobrienexpected) results. 119490075Sobrien 119590075SobrienIf you plan on converting source files which contain such code, it is 119690075Sobrienrecommended that you first make sure that each conditionally compiled 119790075Sobrienregion of source code which contains an alternative function header also 119890075Sobriencontains at least one additional follower token (past the final right 119990075Sobrienparenthesis of the function header). This should circumvent the 120090075Sobrienproblem. 120190075Sobrien 120290075Sobrien@item 120390075Sobrien@command{unprotoize} can become confused when trying to convert a function 120490075Sobriendefinition or declaration which contains a declaration for a 120590075Sobrienpointer-to-function formal argument which has the same name as the 120690075Sobrienfunction being defined or declared. We recommend you avoid such choices 120790075Sobrienof formal parameter names. 120890075Sobrien 120990075Sobrien@item 121090075SobrienYou might also want to correct some of the indentation by hand and break 121190075Sobrienlong lines. (The conversion programs don't write lines longer than 121290075Sobrieneighty characters in any case.) 121390075Sobrien@end itemize 121490075Sobrien 121590075Sobrien@node Non-bugs 121690075Sobrien@section Certain Changes We Don't Want to Make 121790075Sobrien 121890075SobrienThis section lists changes that people frequently request, but which 121990075Sobrienwe do not make because we think GCC is better without them. 122090075Sobrien 122190075Sobrien@itemize @bullet 122290075Sobrien@item 122390075SobrienChecking the number and type of arguments to a function which has an 122490075Sobrienold-fashioned definition and no prototype. 122590075Sobrien 122690075SobrienSuch a feature would work only occasionally---only for calls that appear 122790075Sobrienin the same file as the called function, following the definition. The 122890075Sobrienonly way to check all calls reliably is to add a prototype for the 122990075Sobrienfunction. But adding a prototype eliminates the motivation for this 123090075Sobrienfeature. So the feature is not worthwhile. 123190075Sobrien 123290075Sobrien@item 123390075SobrienWarning about using an expression whose type is signed as a shift count. 123490075Sobrien 123590075SobrienShift count operands are probably signed more often than unsigned. 123690075SobrienWarning about this would cause far more annoyance than good. 123790075Sobrien 123890075Sobrien@item 123990075SobrienWarning about assigning a signed value to an unsigned variable. 124090075Sobrien 124190075SobrienSuch assignments must be very common; warning about them would cause 124290075Sobrienmore annoyance than good. 124390075Sobrien 124490075Sobrien@item 124590075SobrienWarning when a non-void function value is ignored. 124690075Sobrien 1247132718SkanC contains many standard functions that return a value that most 1248132718Skanprograms choose to ignore. One obvious example is @code{printf}. 1249132718SkanWarning about this practice only leads the defensive programmer to 1250132718Skanclutter programs with dozens of casts to @code{void}. Such casts are 1251132718Skanrequired so frequently that they become visual noise. Writing those 1252132718Skancasts becomes so automatic that they no longer convey useful 1253132718Skaninformation about the intentions of the programmer. For functions 1254132718Skanwhere the return value should never be ignored, use the 1255132718Skan@code{warn_unused_result} function attribute (@pxref{Function 1256132718SkanAttributes}). 125790075Sobrien 125890075Sobrien@item 125990075Sobrien@opindex fshort-enums 126090075SobrienMaking @option{-fshort-enums} the default. 126190075Sobrien 126290075SobrienThis would cause storage layout to be incompatible with most other C 126390075Sobriencompilers. And it doesn't seem very important, given that you can get 126490075Sobrienthe same result in other ways. The case where it matters most is when 126590075Sobrienthe enumeration-valued object is inside a structure, and in that case 126690075Sobrienyou can specify a field width explicitly. 126790075Sobrien 126890075Sobrien@item 126990075SobrienMaking bit-fields unsigned by default on particular machines where ``the 127090075SobrienABI standard'' says to do so. 127190075Sobrien 127290075SobrienThe ISO C standard leaves it up to the implementation whether a bit-field 127390075Sobriendeclared plain @code{int} is signed or not. This in effect creates two 127490075Sobrienalternative dialects of C@. 127590075Sobrien 127690075Sobrien@opindex fsigned-bitfields 127790075Sobrien@opindex funsigned-bitfields 127890075SobrienThe GNU C compiler supports both dialects; you can specify the signed 127990075Sobriendialect with @option{-fsigned-bitfields} and the unsigned dialect with 128090075Sobrien@option{-funsigned-bitfields}. However, this leaves open the question of 128190075Sobrienwhich dialect to use by default. 128290075Sobrien 128390075SobrienCurrently, the preferred dialect makes plain bit-fields signed, because 128490075Sobrienthis is simplest. Since @code{int} is the same as @code{signed int} in 128590075Sobrienevery other context, it is cleanest for them to be the same in bit-fields 128690075Sobrienas well. 128790075Sobrien 128890075SobrienSome computer manufacturers have published Application Binary Interface 128990075Sobrienstandards which specify that plain bit-fields should be unsigned. It is 129090075Sobriena mistake, however, to say anything about this issue in an ABI@. This is 129190075Sobrienbecause the handling of plain bit-fields distinguishes two dialects of C@. 129290075SobrienBoth dialects are meaningful on every type of machine. Whether a 129390075Sobrienparticular object file was compiled using signed bit-fields or unsigned 129490075Sobrienis of no concern to other object files, even if they access the same 129590075Sobrienbit-fields in the same data structures. 129690075Sobrien 129790075SobrienA given program is written in one or the other of these two dialects. 129890075SobrienThe program stands a chance to work on most any machine if it is 129990075Sobriencompiled with the proper dialect. It is unlikely to work at all if 130090075Sobriencompiled with the wrong dialect. 130190075Sobrien 130290075SobrienMany users appreciate the GNU C compiler because it provides an 130390075Sobrienenvironment that is uniform across machines. These users would be 130490075Sobrieninconvenienced if the compiler treated plain bit-fields differently on 130590075Sobriencertain machines. 130690075Sobrien 130790075SobrienOccasionally users write programs intended only for a particular machine 130890075Sobrientype. On these occasions, the users would benefit if the GNU C compiler 130990075Sobrienwere to support by default the same dialect as the other compilers on 131090075Sobrienthat machine. But such applications are rare. And users writing a 131190075Sobrienprogram to run on more than one type of machine cannot possibly benefit 131290075Sobrienfrom this kind of compatibility. 131390075Sobrien 131490075SobrienThis is why GCC does and will treat plain bit-fields in the same 131590075Sobrienfashion on all types of machines (by default). 131690075Sobrien 131790075SobrienThere are some arguments for making bit-fields unsigned by default on all 131890075Sobrienmachines. If, for example, this becomes a universal de facto standard, 131990075Sobrienit would make sense for GCC to go along with it. This is something 132090075Sobriento be considered in the future. 132190075Sobrien 132290075Sobrien(Of course, users strongly concerned about portability should indicate 132390075Sobrienexplicitly in each bit-field whether it is signed or not. In this way, 132490075Sobrienthey write programs which have the same meaning in both C dialects.) 132590075Sobrien 132690075Sobrien@item 132790075Sobrien@opindex ansi 132890075Sobrien@opindex std 132990075SobrienUndefining @code{__STDC__} when @option{-ansi} is not used. 133090075Sobrien 1331117395SkanCurrently, GCC defines @code{__STDC__} unconditionally. This provides 1332117395Skangood results in practice. 133390075Sobrien 133490075SobrienProgrammers normally use conditionals on @code{__STDC__} to ask whether 133590075Sobrienit is safe to use certain features of ISO C, such as function 133690075Sobrienprototypes or ISO token concatenation. Since plain @command{gcc} supports 133790075Sobrienall the features of ISO C, the correct answer to these questions is 133890075Sobrien``yes''. 133990075Sobrien 134090075SobrienSome users try to use @code{__STDC__} to check for the availability of 134190075Sobriencertain library facilities. This is actually incorrect usage in an ISO 134290075SobrienC program, because the ISO C standard says that a conforming 134390075Sobrienfreestanding implementation should define @code{__STDC__} even though it 134490075Sobriendoes not have the library facilities. @samp{gcc -ansi -pedantic} is a 134590075Sobrienconforming freestanding implementation, and it is therefore required to 134690075Sobriendefine @code{__STDC__}, even though it does not come with an ISO C 134790075Sobrienlibrary. 134890075Sobrien 134990075SobrienSometimes people say that defining @code{__STDC__} in a compiler that 135090075Sobriendoes not completely conform to the ISO C standard somehow violates the 135190075Sobrienstandard. This is illogical. The standard is a standard for compilers 135290075Sobrienthat claim to support ISO C, such as @samp{gcc -ansi}---not for other 135390075Sobriencompilers such as plain @command{gcc}. Whatever the ISO C standard says 135490075Sobrienis relevant to the design of plain @command{gcc} without @option{-ansi} only 135590075Sobrienfor pragmatic reasons, not as a requirement. 135690075Sobrien 135790075SobrienGCC normally defines @code{__STDC__} to be 1, and in addition 135890075Sobriendefines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, 135990075Sobrienor a @option{-std} option for strict conformance to some version of ISO C@. 136090075SobrienOn some hosts, system include files use a different convention, where 136190075Sobrien@code{__STDC__} is normally 0, but is 1 if the user specifies strict 136290075Sobrienconformance to the C Standard. GCC follows the host convention when 136390075Sobrienprocessing system include files, but when processing user files it follows 136490075Sobrienthe usual GNU C convention. 136590075Sobrien 136690075Sobrien@item 136790075SobrienUndefining @code{__STDC__} in C++. 136890075Sobrien 136990075SobrienPrograms written to compile with C++-to-C translators get the 137090075Sobrienvalue of @code{__STDC__} that goes with the C compiler that is 137190075Sobriensubsequently used. These programs must test @code{__STDC__} 137290075Sobriento determine what kind of C preprocessor that compiler uses: 137390075Sobrienwhether they should concatenate tokens in the ISO C fashion 137490075Sobrienor in the traditional fashion. 137590075Sobrien 137690075SobrienThese programs work properly with GNU C++ if @code{__STDC__} is defined. 137790075SobrienThey would not work otherwise. 137890075Sobrien 137990075SobrienIn addition, many header files are written to provide prototypes in ISO 138090075SobrienC but not in traditional C@. Many of these header files can work without 138190075Sobrienchange in C++ provided @code{__STDC__} is defined. If @code{__STDC__} 138290075Sobrienis not defined, they will all fail, and will all need to be changed to 138390075Sobrientest explicitly for C++ as well. 138490075Sobrien 138590075Sobrien@item 138690075SobrienDeleting ``empty'' loops. 138790075Sobrien 138890075SobrienHistorically, GCC has not deleted ``empty'' loops under the 138990075Sobrienassumption that the most likely reason you would put one in a program is 139090075Sobriento have a delay, so deleting them will not make real programs run any 139190075Sobrienfaster. 139290075Sobrien 139390075SobrienHowever, the rationale here is that optimization of a nonempty loop 139490075Sobriencannot produce an empty one, which holds for C but is not always the 139590075Sobriencase for C++. 139690075Sobrien 139790075Sobrien@opindex funroll-loops 139890075SobrienMoreover, with @option{-funroll-loops} small ``empty'' loops are already 139990075Sobrienremoved, so the current behavior is both sub-optimal and inconsistent 140090075Sobrienand will change in the future. 140190075Sobrien 140290075Sobrien@item 140390075SobrienMaking side effects happen in the same order as in some other compiler. 140490075Sobrien 140590075Sobrien@cindex side effects, order of evaluation 140690075Sobrien@cindex order of evaluation, side effects 140790075SobrienIt is never safe to depend on the order of evaluation of side effects. 140890075SobrienFor example, a function call like this may very well behave differently 140990075Sobrienfrom one compiler to another: 141090075Sobrien 1411132718Skan@smallexample 141290075Sobrienvoid func (int, int); 141390075Sobrien 141490075Sobrienint i = 2; 141590075Sobrienfunc (i++, i++); 1416132718Skan@end smallexample 141790075Sobrien 141890075SobrienThere is no guarantee (in either the C or the C++ standard language 141990075Sobriendefinitions) that the increments will be evaluated in any particular 142090075Sobrienorder. Either increment might happen first. @code{func} might get the 142190075Sobrienarguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. 142290075Sobrien 142390075Sobrien@item 142490075SobrienNot allowing structures with volatile fields in registers. 142590075Sobrien 142690075SobrienStrictly speaking, there is no prohibition in the ISO C standard 142790075Sobrienagainst allowing structures with volatile fields in registers, but 142890075Sobrienit does not seem to make any sense and is probably not what you wanted 142990075Sobriento do. So the compiler will give an error message in this case. 143090075Sobrien 143190075Sobrien@item 143290075SobrienMaking certain warnings into errors by default. 143390075Sobrien 143490075SobrienSome ISO C testsuites report failure when the compiler does not produce 143590075Sobrienan error message for a certain program. 143690075Sobrien 143790075Sobrien@opindex pedantic-errors 143890075SobrienISO C requires a ``diagnostic'' message for certain kinds of invalid 143990075Sobrienprograms, but a warning is defined by GCC to count as a diagnostic. If 144090075SobrienGCC produces a warning but not an error, that is correct ISO C support. 1441132718SkanIf testsuites call this ``failure'', they should be run with the GCC 144290075Sobrienoption @option{-pedantic-errors}, which will turn these warnings into 144390075Sobrienerrors. 144490075Sobrien 144590075Sobrien@end itemize 144690075Sobrien 144790075Sobrien@node Warnings and Errors 144890075Sobrien@section Warning Messages and Error Messages 144990075Sobrien 145090075Sobrien@cindex error messages 145190075Sobrien@cindex warnings vs errors 145290075Sobrien@cindex messages, warning and error 145390075SobrienThe GNU compiler can produce two kinds of diagnostics: errors and 145490075Sobrienwarnings. Each kind has a different purpose: 145590075Sobrien 145690075Sobrien@itemize @w{} 145790075Sobrien@item 145890075Sobrien@dfn{Errors} report problems that make it impossible to compile your 145990075Sobrienprogram. GCC reports errors with the source file name and line 146090075Sobriennumber where the problem is apparent. 146190075Sobrien 146290075Sobrien@item 146390075Sobrien@dfn{Warnings} report other unusual conditions in your code that 146490075Sobrien@emph{may} indicate a problem, although compilation can (and does) 146590075Sobrienproceed. Warning messages also report the source file name and line 146690075Sobriennumber, but include the text @samp{warning:} to distinguish them 146790075Sobrienfrom error messages. 146890075Sobrien@end itemize 146990075Sobrien 147090075SobrienWarnings may indicate danger points where you should check to make sure 147190075Sobrienthat your program really does what you intend; or the use of obsolete 147290075Sobrienfeatures; or the use of nonstandard features of GNU C or C++. Many 147390075Sobrienwarnings are issued only if you ask for them, with one of the @option{-W} 147490075Sobrienoptions (for instance, @option{-Wall} requests a variety of useful 147590075Sobrienwarnings). 147690075Sobrien 147790075Sobrien@opindex pedantic 147890075Sobrien@opindex pedantic-errors 147990075SobrienGCC always tries to compile your program if possible; it never 148090075Sobriengratuitously rejects a program whose meaning is clear merely because 148190075Sobrien(for instance) it fails to conform to a standard. In some cases, 148290075Sobrienhowever, the C and C++ standards specify that certain extensions are 148390075Sobrienforbidden, and a diagnostic @emph{must} be issued by a conforming 148490075Sobriencompiler. The @option{-pedantic} option tells GCC to issue warnings in 148590075Sobriensuch cases; @option{-pedantic-errors} says to make them errors instead. 148690075SobrienThis does not mean that @emph{all} non-ISO constructs get warnings 148790075Sobrienor errors. 148890075Sobrien 148990075Sobrien@xref{Warning Options,,Options to Request or Suppress Warnings}, for 149090075Sobrienmore detail on these and related command-line options. 1491