trouble.texi revision 117395
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 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 37790075Sobrien@example 37890075Sobrien#ifdef __STDC__ 37990075Sobrien#define NeedFunctionPrototypes 0 38090075Sobrien#endif 38190075Sobrien@end example 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 39690075Sobrien@example 39790075SobrienMALLOC=/usr/local/lib/libgmalloc.a 39890075Sobrien@end example 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 40490075Sobrien@example 40590075SobrienMALLOC=gmalloc.o 40690075Sobrien@end example 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 45790075Sobrien@example 45890075Sobrien#define foo(a) "a" 45990075Sobrien@end example 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 47290075Sobrien@example 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@} 48790075Sobrien@end example 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 50390075Sobrien@example 50490075Sobrien@group 50590075Sobrienfoobar ( 50690075Sobrien#define luser 50790075Sobrien hack) 50890075Sobrien@end group 50990075Sobrien@end example 51090075Sobrien 511117395SkanISO C does not permit such a construct. 51290075Sobrien 51390075Sobrien@item 51490075SobrienK&R compilers allow comments to cross over an inclusion boundary 51590075Sobrien(i.e.@: started in an include file and ended in the including file). I think 51690075Sobrienthis would be quite ugly and can't imagine it could be needed. 51790075Sobrien 51890075Sobrien@cindex external declaration scope 51990075Sobrien@cindex scope of external declarations 52090075Sobrien@cindex declaration scope 52190075Sobrien@item 52290075SobrienDeclarations of external variables and functions within a block apply 52390075Sobrienonly to the block containing the declaration. In other words, they 52490075Sobrienhave the same scope as any other declaration in the same place. 52590075Sobrien 52690075SobrienIn some other C compilers, a @code{extern} declaration affects all the 52790075Sobrienrest of the file even if it happens within a block. 52890075Sobrien 52990075Sobrien@item 53090075SobrienIn traditional C, you can combine @code{long}, etc., with a typedef name, 53190075Sobrienas shown here: 53290075Sobrien 53390075Sobrien@example 53490075Sobrientypedef int foo; 53590075Sobrientypedef long foo bar; 53690075Sobrien@end example 53790075Sobrien 53890075SobrienIn ISO C, this is not allowed: @code{long} and other type modifiers 539117395Skanrequire an explicit @code{int}. 54090075Sobrien 54190075Sobrien@cindex typedef names as function parameters 54290075Sobrien@item 543117395SkanPCC allows typedef names to be used as function parameters. 54490075Sobrien 54590075Sobrien@item 546117395SkanTraditional C allows the following erroneous pair of declarations to 547117395Skanappear together in a given scope: 54890075Sobrien 54990075Sobrien@example 55090075Sobrientypedef int foo; 55190075Sobrientypedef foo foo; 55290075Sobrien@end example 55390075Sobrien 55490075Sobrien@item 555117395SkanGCC treats all characters of identifiers as significant. According to 556117395SkanK&R-1 (2.2), ``No more than the first eight characters are significant, 557117395Skanalthough more may be used.''. Also according to K&R-1 (2.2), ``An 558117395Skanidentifier is a sequence of letters and digits; the first character must 559117395Skanbe a letter. The underscore _ counts as a letter.'', but GCC also 560117395Skanallows dollar signs in identifiers. 56190075Sobrien 56290075Sobrien@cindex whitespace 56390075Sobrien@item 56490075SobrienPCC allows whitespace in the middle of compound assignment operators 56590075Sobriensuch as @samp{+=}. GCC, following the ISO standard, does not 566117395Skanallow this. 56790075Sobrien 56890075Sobrien@cindex apostrophes 56990075Sobrien@cindex ' 57090075Sobrien@item 57190075SobrienGCC complains about unterminated character constants inside of 57290075Sobrienpreprocessing conditionals that fail. Some programs have English 57390075Sobriencomments enclosed in conditionals that are guaranteed to fail; if these 57490075Sobriencomments contain apostrophes, GCC will probably report an error. For 57590075Sobrienexample, this code would produce an error: 57690075Sobrien 57790075Sobrien@example 57890075Sobrien#if 0 57990075SobrienYou can't expect this to work. 58090075Sobrien#endif 58190075Sobrien@end example 58290075Sobrien 58390075SobrienThe best solution to such a problem is to put the text into an actual 584117395SkanC comment delimited by @samp{/*@dots{}*/}. 58590075Sobrien 58690075Sobrien@item 58790075SobrienMany user programs contain the declaration @samp{long time ();}. In the 58890075Sobrienpast, the system header files on many systems did not actually declare 58990075Sobrien@code{time}, so it did not matter what type your program declared it to 59090075Sobrienreturn. But in systems with ISO C headers, @code{time} is declared to 59190075Sobrienreturn @code{time_t}, and if that is not the same as @code{long}, then 59290075Sobrien@samp{long time ();} is erroneous. 59390075Sobrien 59490075SobrienThe solution is to change your program to use appropriate system headers 59590075Sobrien(@code{<time.h>} on systems with ISO C headers) and not to declare 59690075Sobrien@code{time} if the system header files declare it, or failing that to 59790075Sobrienuse @code{time_t} as the return type of @code{time}. 59890075Sobrien 59990075Sobrien@cindex @code{float} as function value type 60090075Sobrien@item 60190075SobrienWhen compiling functions that return @code{float}, PCC converts it to 60290075Sobriena double. GCC actually returns a @code{float}. If you are concerned 60390075Sobrienwith PCC compatibility, you should declare your functions to return 60490075Sobrien@code{double}; you might as well say what you mean. 60590075Sobrien 60690075Sobrien@cindex structures 60790075Sobrien@cindex unions 60890075Sobrien@item 60990075SobrienWhen compiling functions that return structures or unions, GCC 61090075Sobrienoutput code normally uses a method different from that used on most 61190075Sobrienversions of Unix. As a result, code compiled with GCC cannot call 61290075Sobriena structure-returning function compiled with PCC, and vice versa. 61390075Sobrien 61490075SobrienThe method used by GCC is as follows: a structure or union which is 61590075Sobrien1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union 61690075Sobrienwith any other size is stored into an address supplied by the caller 61790075Sobrien(usually in a special, fixed register, but on some machines it is passed 61890075Sobrienon the stack). The machine-description macros @code{STRUCT_VALUE} and 61990075Sobrien@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address. 62090075Sobrien 62190075SobrienBy contrast, PCC on most target machines returns structures and unions 62290075Sobrienof any size by copying the data into an area of static storage, and then 62390075Sobrienreturning the address of that storage as if it were a pointer value. 62490075SobrienThe caller must copy the data from that memory area to the place where 62590075Sobrienthe value is wanted. GCC does not use this method because it is 62690075Sobrienslower and nonreentrant. 62790075Sobrien 62890075SobrienOn some newer machines, PCC uses a reentrant convention for all 62990075Sobrienstructure and union returning. GCC on most of these machines uses a 63090075Sobriencompatible convention when returning structures and unions in memory, 63190075Sobrienbut still returns small structures and unions in registers. 63290075Sobrien 63390075Sobrien@opindex fpcc-struct-return 63490075SobrienYou can tell GCC to use a compatible convention for all structure and 63590075Sobrienunion returning with the option @option{-fpcc-struct-return}. 63690075Sobrien 63790075Sobrien@cindex preprocessing tokens 63890075Sobrien@cindex preprocessing numbers 63990075Sobrien@item 64090075SobrienGCC complains about program fragments such as @samp{0x74ae-0x4000} 64190075Sobrienwhich appear to be two hexadecimal constants separated by the minus 64290075Sobrienoperator. Actually, this string is a single @dfn{preprocessing token}. 64390075SobrienEach such token must correspond to one token in C@. Since this does not, 64490075SobrienGCC prints an error message. Although it may appear obvious that what 64590075Sobrienis meant is an operator and two values, the ISO C standard specifically 64690075Sobrienrequires that this be treated as erroneous. 64790075Sobrien 64890075SobrienA @dfn{preprocessing token} is a @dfn{preprocessing number} if it 64990075Sobrienbegins with a digit and is followed by letters, underscores, digits, 65090075Sobrienperiods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, 65190075Sobrien@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89 65290075Sobrienmode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot 65390075Sobrienappear in preprocessing numbers.) 65490075Sobrien 65590075SobrienTo make the above program fragment valid, place whitespace in front of 65690075Sobrienthe minus sign. This whitespace will end the preprocessing number. 65790075Sobrien@end itemize 65890075Sobrien 65990075Sobrien@node Fixed Headers 66090075Sobrien@section Fixed Header Files 66190075Sobrien 66290075SobrienGCC needs to install corrected versions of some system header files. 66390075SobrienThis is because most target systems have some header files that won't 66490075Sobrienwork with GCC unless they are changed. Some have bugs, some are 66590075Sobrienincompatible with ISO C, and some depend on special features of other 66690075Sobriencompilers. 66790075Sobrien 66890075SobrienInstalling GCC automatically creates and installs the fixed header 66990075Sobrienfiles, by running a program called @code{fixincludes} (or for certain 67090075Sobrientargets an alternative such as @code{fixinc.svr4}). Normally, you 67190075Sobriendon't need to pay attention to this. But there are cases where it 67290075Sobriendoesn't do the right thing automatically. 67390075Sobrien 67490075Sobrien@itemize @bullet 67590075Sobrien@item 67690075SobrienIf you update the system's header files, such as by installing a new 67790075Sobriensystem version, the fixed header files of GCC are not automatically 67890075Sobrienupdated. The easiest way to update them is to reinstall GCC@. (If 67990075Sobrienyou want to be clever, look in the makefile and you can find a 68090075Sobrienshortcut.) 68190075Sobrien 68290075Sobrien@item 68390075SobrienOn some systems, in particular SunOS 4, header file directories contain 68490075Sobrienmachine-specific symbolic links in certain places. This makes it 68590075Sobrienpossible to share most of the header files among hosts running the 68690075Sobriensame version of SunOS 4 on different machine models. 68790075Sobrien 68890075SobrienThe programs that fix the header files do not understand this special 68990075Sobrienway of using symbolic links; therefore, the directory of fixed header 69090075Sobrienfiles is good only for the machine model used to build it. 69190075Sobrien 69290075SobrienIn SunOS 4, only programs that look inside the kernel will notice the 69390075Sobriendifference between machine models. Therefore, for most purposes, you 69490075Sobrienneed not be concerned about this. 69590075Sobrien 69690075SobrienIt is possible to make separate sets of fixed header files for the 69790075Sobriendifferent machine models, and arrange a structure of symbolic links so 69890075Sobrienas to use the proper set, but you'll have to do this by hand. 69990075Sobrien 70090075Sobrien@item 70190075SobrienOn Lynxos, GCC by default does not fix the header files. This is 70290075Sobrienbecause bugs in the shell cause the @code{fixincludes} script to fail. 70390075Sobrien 70490075SobrienThis means you will encounter problems due to bugs in the system header 70590075Sobrienfiles. It may be no comfort that they aren't GCC's fault, but it 70690075Sobriendoes mean that there's nothing for us to do about them. 70790075Sobrien@end itemize 70890075Sobrien 70990075Sobrien@node Standard Libraries 71090075Sobrien@section Standard Libraries 71190075Sobrien 71290075Sobrien@opindex Wall 71390075SobrienGCC by itself attempts to be a conforming freestanding implementation. 71490075Sobrien@xref{Standards,,Language Standards Supported by GCC}, for details of 71590075Sobrienwhat this means. Beyond the library facilities required of such an 71690075Sobrienimplementation, the rest of the C library is supplied by the vendor of 71790075Sobrienthe operating system. If that C library doesn't conform to the C 71890075Sobrienstandards, then your programs might get warnings (especially when using 71990075Sobrien@option{-Wall}) that you don't expect. 72090075Sobrien 72190075SobrienFor example, the @code{sprintf} function on SunOS 4.1.3 returns 72290075Sobrien@code{char *} while the C standard says that @code{sprintf} returns an 72390075Sobrien@code{int}. The @code{fixincludes} program could make the prototype for 72490075Sobrienthis function match the Standard, but that would be wrong, since the 72590075Sobrienfunction will still return @code{char *}. 72690075Sobrien 72790075SobrienIf you need a Standard compliant library, then you need to find one, as 72890075SobrienGCC does not provide one. The GNU C library (called @code{glibc}) 72990075Sobrienprovides ISO C, POSIX, BSD, SystemV and X/Open compatibility for 73090075SobrienGNU/Linux and HURD-based GNU systems; no recent version of it supports 73190075Sobrienother systems, though some very old versions did. Version 2.2 of the 73290075SobrienGNU C library includes nearly complete C99 support. You could also ask 73390075Sobrienyour operating system vendor if newer libraries are available. 73490075Sobrien 73590075Sobrien@node Disappointments 73690075Sobrien@section Disappointments and Misunderstandings 73790075Sobrien 73890075SobrienThese problems are perhaps regrettable, but we don't know any practical 73990075Sobrienway around them. 74090075Sobrien 74190075Sobrien@itemize @bullet 74290075Sobrien@item 74390075SobrienCertain local variables aren't recognized by debuggers when you compile 74490075Sobrienwith optimization. 74590075Sobrien 74690075SobrienThis occurs because sometimes GCC optimizes the variable out of 74790075Sobrienexistence. There is no way to tell the debugger how to compute the 74890075Sobrienvalue such a variable ``would have had'', and it is not clear that would 74990075Sobrienbe desirable anyway. So GCC simply does not mention the eliminated 75090075Sobrienvariable when it writes debugging information. 75190075Sobrien 75290075SobrienYou have to expect a certain amount of disagreement between the 75390075Sobrienexecutable and your source code, when you use optimization. 75490075Sobrien 75590075Sobrien@cindex conflicting types 75690075Sobrien@cindex scope of declaration 75790075Sobrien@item 75890075SobrienUsers often think it is a bug when GCC reports an error for code 75990075Sobrienlike this: 76090075Sobrien 76190075Sobrien@example 76290075Sobrienint foo (struct mumble *); 76390075Sobrien 76490075Sobrienstruct mumble @{ @dots{} @}; 76590075Sobrien 76690075Sobrienint foo (struct mumble *x) 76790075Sobrien@{ @dots{} @} 76890075Sobrien@end example 76990075Sobrien 77090075SobrienThis code really is erroneous, because the scope of @code{struct 77190075Sobrienmumble} in the prototype is limited to the argument list containing it. 77290075SobrienIt does not refer to the @code{struct mumble} defined with file scope 77390075Sobrienimmediately below---they are two unrelated types with similar names in 77490075Sobriendifferent scopes. 77590075Sobrien 77690075SobrienBut in the definition of @code{foo}, the file-scope type is used 77790075Sobrienbecause that is available to be inherited. Thus, the definition and 77890075Sobrienthe prototype do not match, and you get an error. 77990075Sobrien 78090075SobrienThis behavior may seem silly, but it's what the ISO standard specifies. 78190075SobrienIt is easy enough for you to make your code work by moving the 78290075Sobriendefinition of @code{struct mumble} above the prototype. It's not worth 78390075Sobrienbeing incompatible with ISO C just to avoid an error for the example 78490075Sobrienshown above. 78590075Sobrien 78690075Sobrien@item 78790075SobrienAccesses to bit-fields even in volatile objects works by accessing larger 78890075Sobrienobjects, such as a byte or a word. You cannot rely on what size of 78990075Sobrienobject is accessed in order to read or write the bit-field; it may even 79090075Sobrienvary for a given bit-field according to the precise usage. 79190075Sobrien 79290075SobrienIf you care about controlling the amount of memory that is accessed, use 79390075Sobrienvolatile but do not use bit-fields. 79490075Sobrien 79590075Sobrien@item 79690075SobrienGCC comes with shell scripts to fix certain known problems in system 79790075Sobrienheader files. They install corrected copies of various header files in 79890075Sobriena special directory where only GCC will normally look for them. The 79990075Sobrienscripts adapt to various systems by searching all the system header 80090075Sobrienfiles for the problem cases that we know about. 80190075Sobrien 80290075SobrienIf new system header files are installed, nothing automatically arranges 80390075Sobriento update the corrected header files. You will have to reinstall GCC 80490075Sobriento fix the new header files. More specifically, go to the build 80590075Sobriendirectory and delete the files @file{stmp-fixinc} and 80690075Sobrien@file{stmp-headers}, and the subdirectory @code{include}; then do 80790075Sobrien@samp{make install} again. 80890075Sobrien 80990075Sobrien@item 81090075Sobrien@cindex floating point precision 81190075SobrienOn 68000 and x86 systems, for instance, you can get paradoxical results 81290075Sobrienif you test the precise values of floating point numbers. For example, 81390075Sobrienyou can find that a floating point value which is not a NaN is not equal 81490075Sobriento itself. This results from the fact that the floating point registers 81590075Sobrienhold a few more bits of precision than fit in a @code{double} in memory. 81690075SobrienCompiled code moves values between memory and floating point registers 81790075Sobrienat its convenience, and moving them into memory truncates them. 81890075Sobrien 81990075Sobrien@opindex ffloat-store 82090075SobrienYou can partially avoid this problem by using the @option{-ffloat-store} 82190075Sobrienoption (@pxref{Optimize Options}). 82290075Sobrien 82390075Sobrien@item 82490075SobrienOn AIX and other platforms without weak symbol support, templates 82590075Sobrienneed to be instantiated explicitly and symbols for static members 82690075Sobrienof templates will not be generated. 827117395Skan 828117395Skan@item 829117395SkanOn AIX, GCC scans object files and library archives for static 830117395Skanconstructors and destructors when linking an application before the 831117395Skanlinker prunes unreferenced symbols. This is necessary to prevent the 832117395SkanAIX linker from mistakenly assuming that static constructor or 833117395Skandestructor are unused and removing them before the scanning can occur. 834117395SkanAll static constructors and destructors found will be referenced even 835117395Skanthough the modules in which they occur may not be used by the program. 836117395SkanThis may lead to both increased executable size and unexpected symbol 837117395Skanreferences. 83890075Sobrien@end itemize 83990075Sobrien 84090075Sobrien@node C++ Misunderstandings 84190075Sobrien@section Common Misunderstandings with GNU C++ 84290075Sobrien 84390075Sobrien@cindex misunderstandings in C++ 84490075Sobrien@cindex surprises in C++ 84590075Sobrien@cindex C++ misunderstandings 84690075SobrienC++ is a complex language and an evolving one, and its standard 84790075Sobriendefinition (the ISO C++ standard) was only recently completed. As a 84890075Sobrienresult, your C++ compiler may occasionally surprise you, even when its 84990075Sobrienbehavior is correct. This section discusses some areas that frequently 85090075Sobriengive rise to questions of this sort. 85190075Sobrien 85290075Sobrien@menu 85390075Sobrien* Static Definitions:: Static member declarations are not definitions 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 86890075Sobrien@example 86990075Sobrienclass Foo 87090075Sobrien@{ 87190075Sobrien @dots{} 87290075Sobrien void method(); 87390075Sobrien static int bar; 87490075Sobrien@}; 87590075Sobrien@end example 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 88490075Sobrien@example 88590075Sobrienint Foo::bar = 0; 88690075Sobrien@end example 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 89490075Sobrien@node Temporaries 89590075Sobrien@subsection Temporaries May Vanish Before You Expect 89690075Sobrien 89790075Sobrien@cindex temporaries, lifetime of 89890075Sobrien@cindex portions of temporary objects, pointers to 89990075SobrienIt is dangerous to use pointers or references to @emph{portions} of a 90090075Sobrientemporary object. The compiler may very well delete the object before 90190075Sobrienyou expect it to, leaving a pointer to garbage. The most common place 90290075Sobrienwhere this problem crops up is in classes like string classes, 90390075Sobrienespecially ones that define a conversion function to type @code{char *} 90490075Sobrienor @code{const char *}---which is one reason why the standard 90590075Sobrien@code{string} class requires you to call the @code{c_str} member 90690075Sobrienfunction. However, any class that returns a pointer to some internal 90790075Sobrienstructure is potentially subject to this problem. 90890075Sobrien 90990075SobrienFor example, a program may use a function @code{strfunc} that returns 91090075Sobrien@code{string} objects, and another function @code{charfunc} that 91190075Sobrienoperates on pointers to @code{char}: 91290075Sobrien 91390075Sobrien@example 91490075Sobrienstring strfunc (); 91590075Sobrienvoid charfunc (const char *); 91690075Sobrien 91790075Sobrienvoid 91890075Sobrienf () 91990075Sobrien@{ 92090075Sobrien const char *p = strfunc().c_str(); 92190075Sobrien @dots{} 92290075Sobrien charfunc (p); 92390075Sobrien @dots{} 92490075Sobrien charfunc (p); 92590075Sobrien@} 92690075Sobrien@end example 92790075Sobrien 92890075Sobrien@noindent 92990075SobrienIn this situation, it may seem reasonable to save a pointer to the C 93090075Sobrienstring returned by the @code{c_str} member function and use that rather 93190075Sobrienthan call @code{c_str} repeatedly. However, the temporary string 93290075Sobriencreated by the call to @code{strfunc} is destroyed after @code{p} is 93390075Sobrieninitialized, at which point @code{p} is left pointing to freed memory. 93490075Sobrien 93590075SobrienCode like this may run successfully under some other compilers, 93690075Sobrienparticularly obsolete cfront-based compilers that delete temporaries 93790075Sobrienalong with normal local variables. However, the GNU C++ behavior is 93890075Sobrienstandard-conforming, so if your program depends on late destruction of 93990075Sobrientemporaries it is not portable. 94090075Sobrien 94190075SobrienThe safe way to write such code is to give the temporary a name, which 94290075Sobrienforces it to remain until the end of the scope of the name. For 94390075Sobrienexample: 94490075Sobrien 94590075Sobrien@example 94690075Sobrienstring& tmp = strfunc (); 94790075Sobriencharfunc (tmp.c_str ()); 94890075Sobrien@end example 94990075Sobrien 95090075Sobrien@node Copy Assignment 95190075Sobrien@subsection Implicit Copy-Assignment for Virtual Bases 95290075Sobrien 95390075SobrienWhen a base class is virtual, only one subobject of the base class 95490075Sobrienbelongs to each full object. Also, the constructors and destructors are 95590075Sobrieninvoked only once, and called from the most-derived class. However, such 95690075Sobrienobjects behave unspecified when being assigned. For example: 95790075Sobrien 95890075Sobrien@example 95990075Sobrienstruct Base@{ 96090075Sobrien char *name; 96190075Sobrien Base(char *n) : name(strdup(n))@{@} 96290075Sobrien Base& operator= (const Base& other)@{ 96390075Sobrien free (name); 96490075Sobrien name = strdup (other.name); 96590075Sobrien @} 96690075Sobrien@}; 96790075Sobrien 96890075Sobrienstruct A:virtual Base@{ 96990075Sobrien int val; 97090075Sobrien A():Base("A")@{@} 97190075Sobrien@}; 97290075Sobrien 97390075Sobrienstruct B:virtual Base@{ 97490075Sobrien int bval; 97590075Sobrien B():Base("B")@{@} 97690075Sobrien@}; 97790075Sobrien 97890075Sobrienstruct Derived:public A, public B@{ 97990075Sobrien Derived():Base("Derived")@{@} 98090075Sobrien@}; 98190075Sobrien 98290075Sobrienvoid func(Derived &d1, Derived &d2) 98390075Sobrien@{ 98490075Sobrien d1 = d2; 98590075Sobrien@} 98690075Sobrien@end example 98790075Sobrien 98890075SobrienThe C++ standard specifies that @samp{Base::Base} is only called once 98990075Sobrienwhen constructing or copy-constructing a Derived object. It is 99090075Sobrienunspecified whether @samp{Base::operator=} is called more than once when 99190075Sobrienthe implicit copy-assignment for Derived objects is invoked (as it is 99290075Sobrieninside @samp{func} in the example). 99390075Sobrien 99490075Sobrieng++ implements the ``intuitive'' algorithm for copy-assignment: assign all 99590075Sobriendirect bases, then assign all members. In that algorithm, the virtual 99690075Sobrienbase subobject can be encountered many times. In the example, copying 99790075Sobrienproceeds in the following order: @samp{val}, @samp{name} (via 99890075Sobrien@code{strdup}), @samp{bval}, and @samp{name} again. 99990075Sobrien 100090075SobrienIf application code relies on copy-assignment, a user-defined 100190075Sobriencopy-assignment operator removes any uncertainties. With such an 100290075Sobrienoperator, the application can define whether and how the virtual base 100390075Sobriensubobject is assigned. 100490075Sobrien 100590075Sobrien@node Protoize Caveats 100690075Sobrien@section Caveats of using @command{protoize} 100790075Sobrien 100890075SobrienThe conversion programs @command{protoize} and @command{unprotoize} can 100990075Sobriensometimes change a source file in a way that won't work unless you 101090075Sobrienrearrange it. 101190075Sobrien 101290075Sobrien@itemize @bullet 101390075Sobrien@item 101490075Sobrien@command{protoize} can insert references to a type name or type tag before 101590075Sobrienthe definition, or in a file where they are not defined. 101690075Sobrien 101790075SobrienIf this happens, compiler error messages should show you where the new 101890075Sobrienreferences are, so fixing the file by hand is straightforward. 101990075Sobrien 102090075Sobrien@item 102190075SobrienThere are some C constructs which @command{protoize} cannot figure out. 102290075SobrienFor example, it can't determine argument types for declaring a 102390075Sobrienpointer-to-function variable; this you must do by hand. @command{protoize} 102490075Sobrieninserts a comment containing @samp{???} each time it finds such a 102590075Sobrienvariable; so you can find all such variables by searching for this 102690075Sobrienstring. ISO C does not require declaring the argument types of 102790075Sobrienpointer-to-function types. 102890075Sobrien 102990075Sobrien@item 103090075SobrienUsing @command{unprotoize} can easily introduce bugs. If the program 103190075Sobrienrelied on prototypes to bring about conversion of arguments, these 103290075Sobrienconversions will not take place in the program without prototypes. 103390075SobrienOne case in which you can be sure @command{unprotoize} is safe is when 103490075Sobrienyou are removing prototypes that were made with @command{protoize}; if 103590075Sobrienthe program worked before without any prototypes, it will work again 103690075Sobrienwithout them. 103790075Sobrien 103890075Sobrien@opindex Wconversion 103990075SobrienYou can find all the places where this problem might occur by compiling 104090075Sobrienthe program with the @option{-Wconversion} option. It prints a warning 104190075Sobrienwhenever an argument is converted. 104290075Sobrien 104390075Sobrien@item 104490075SobrienBoth conversion programs can be confused if there are macro calls in and 104590075Sobrienaround the text to be converted. In other words, the standard syntax 104690075Sobrienfor a declaration or definition must not result from expanding a macro. 104790075SobrienThis problem is inherent in the design of C and cannot be fixed. If 104890075Sobrienonly a few functions have confusing macro calls, you can easily convert 104990075Sobrienthem manually. 105090075Sobrien 105190075Sobrien@item 105290075Sobrien@command{protoize} cannot get the argument types for a function whose 105390075Sobriendefinition was not actually compiled due to preprocessing conditionals. 105490075SobrienWhen this happens, @command{protoize} changes nothing in regard to such 105590075Sobriena function. @command{protoize} tries to detect such instances and warn 105690075Sobrienabout them. 105790075Sobrien 105890075SobrienYou can generally work around this problem by using @command{protoize} step 105990075Sobrienby step, each time specifying a different set of @option{-D} options for 106090075Sobriencompilation, until all of the functions have been converted. There is 106190075Sobrienno automatic way to verify that you have got them all, however. 106290075Sobrien 106390075Sobrien@item 106490075SobrienConfusion may result if there is an occasion to convert a function 106590075Sobriendeclaration or definition in a region of source code where there is more 106690075Sobrienthan one formal parameter list present. Thus, attempts to convert code 106790075Sobriencontaining multiple (conditionally compiled) versions of a single 106890075Sobrienfunction header (in the same vicinity) may not produce the desired (or 106990075Sobrienexpected) results. 107090075Sobrien 107190075SobrienIf you plan on converting source files which contain such code, it is 107290075Sobrienrecommended that you first make sure that each conditionally compiled 107390075Sobrienregion of source code which contains an alternative function header also 107490075Sobriencontains at least one additional follower token (past the final right 107590075Sobrienparenthesis of the function header). This should circumvent the 107690075Sobrienproblem. 107790075Sobrien 107890075Sobrien@item 107990075Sobrien@command{unprotoize} can become confused when trying to convert a function 108090075Sobriendefinition or declaration which contains a declaration for a 108190075Sobrienpointer-to-function formal argument which has the same name as the 108290075Sobrienfunction being defined or declared. We recommend you avoid such choices 108390075Sobrienof formal parameter names. 108490075Sobrien 108590075Sobrien@item 108690075SobrienYou might also want to correct some of the indentation by hand and break 108790075Sobrienlong lines. (The conversion programs don't write lines longer than 108890075Sobrieneighty characters in any case.) 108990075Sobrien@end itemize 109090075Sobrien 109190075Sobrien@node Non-bugs 109290075Sobrien@section Certain Changes We Don't Want to Make 109390075Sobrien 109490075SobrienThis section lists changes that people frequently request, but which 109590075Sobrienwe do not make because we think GCC is better without them. 109690075Sobrien 109790075Sobrien@itemize @bullet 109890075Sobrien@item 109990075SobrienChecking the number and type of arguments to a function which has an 110090075Sobrienold-fashioned definition and no prototype. 110190075Sobrien 110290075SobrienSuch a feature would work only occasionally---only for calls that appear 110390075Sobrienin the same file as the called function, following the definition. The 110490075Sobrienonly way to check all calls reliably is to add a prototype for the 110590075Sobrienfunction. But adding a prototype eliminates the motivation for this 110690075Sobrienfeature. So the feature is not worthwhile. 110790075Sobrien 110890075Sobrien@item 110990075SobrienWarning about using an expression whose type is signed as a shift count. 111090075Sobrien 111190075SobrienShift count operands are probably signed more often than unsigned. 111290075SobrienWarning about this would cause far more annoyance than good. 111390075Sobrien 111490075Sobrien@item 111590075SobrienWarning about assigning a signed value to an unsigned variable. 111690075Sobrien 111790075SobrienSuch assignments must be very common; warning about them would cause 111890075Sobrienmore annoyance than good. 111990075Sobrien 112090075Sobrien@item 112190075SobrienWarning when a non-void function value is ignored. 112290075Sobrien 112390075SobrienComing as I do from a Lisp background, I balk at the idea that there is 112490075Sobriensomething dangerous about discarding a value. There are functions that 112590075Sobrienreturn values which some callers may find useful; it makes no sense to 112690075Sobrienclutter the program with a cast to @code{void} whenever the value isn't 112790075Sobrienuseful. 112890075Sobrien 112990075Sobrien@item 113090075Sobrien@opindex fshort-enums 113190075SobrienMaking @option{-fshort-enums} the default. 113290075Sobrien 113390075SobrienThis would cause storage layout to be incompatible with most other C 113490075Sobriencompilers. And it doesn't seem very important, given that you can get 113590075Sobrienthe same result in other ways. The case where it matters most is when 113690075Sobrienthe enumeration-valued object is inside a structure, and in that case 113790075Sobrienyou can specify a field width explicitly. 113890075Sobrien 113990075Sobrien@item 114090075SobrienMaking bit-fields unsigned by default on particular machines where ``the 114190075SobrienABI standard'' says to do so. 114290075Sobrien 114390075SobrienThe ISO C standard leaves it up to the implementation whether a bit-field 114490075Sobriendeclared plain @code{int} is signed or not. This in effect creates two 114590075Sobrienalternative dialects of C@. 114690075Sobrien 114790075Sobrien@opindex fsigned-bitfields 114890075Sobrien@opindex funsigned-bitfields 114990075SobrienThe GNU C compiler supports both dialects; you can specify the signed 115090075Sobriendialect with @option{-fsigned-bitfields} and the unsigned dialect with 115190075Sobrien@option{-funsigned-bitfields}. However, this leaves open the question of 115290075Sobrienwhich dialect to use by default. 115390075Sobrien 115490075SobrienCurrently, the preferred dialect makes plain bit-fields signed, because 115590075Sobrienthis is simplest. Since @code{int} is the same as @code{signed int} in 115690075Sobrienevery other context, it is cleanest for them to be the same in bit-fields 115790075Sobrienas well. 115890075Sobrien 115990075SobrienSome computer manufacturers have published Application Binary Interface 116090075Sobrienstandards which specify that plain bit-fields should be unsigned. It is 116190075Sobriena mistake, however, to say anything about this issue in an ABI@. This is 116290075Sobrienbecause the handling of plain bit-fields distinguishes two dialects of C@. 116390075SobrienBoth dialects are meaningful on every type of machine. Whether a 116490075Sobrienparticular object file was compiled using signed bit-fields or unsigned 116590075Sobrienis of no concern to other object files, even if they access the same 116690075Sobrienbit-fields in the same data structures. 116790075Sobrien 116890075SobrienA given program is written in one or the other of these two dialects. 116990075SobrienThe program stands a chance to work on most any machine if it is 117090075Sobriencompiled with the proper dialect. It is unlikely to work at all if 117190075Sobriencompiled with the wrong dialect. 117290075Sobrien 117390075SobrienMany users appreciate the GNU C compiler because it provides an 117490075Sobrienenvironment that is uniform across machines. These users would be 117590075Sobrieninconvenienced if the compiler treated plain bit-fields differently on 117690075Sobriencertain machines. 117790075Sobrien 117890075SobrienOccasionally users write programs intended only for a particular machine 117990075Sobrientype. On these occasions, the users would benefit if the GNU C compiler 118090075Sobrienwere to support by default the same dialect as the other compilers on 118190075Sobrienthat machine. But such applications are rare. And users writing a 118290075Sobrienprogram to run on more than one type of machine cannot possibly benefit 118390075Sobrienfrom this kind of compatibility. 118490075Sobrien 118590075SobrienThis is why GCC does and will treat plain bit-fields in the same 118690075Sobrienfashion on all types of machines (by default). 118790075Sobrien 118890075SobrienThere are some arguments for making bit-fields unsigned by default on all 118990075Sobrienmachines. If, for example, this becomes a universal de facto standard, 119090075Sobrienit would make sense for GCC to go along with it. This is something 119190075Sobriento be considered in the future. 119290075Sobrien 119390075Sobrien(Of course, users strongly concerned about portability should indicate 119490075Sobrienexplicitly in each bit-field whether it is signed or not. In this way, 119590075Sobrienthey write programs which have the same meaning in both C dialects.) 119690075Sobrien 119790075Sobrien@item 119890075Sobrien@opindex ansi 119990075Sobrien@opindex std 120090075SobrienUndefining @code{__STDC__} when @option{-ansi} is not used. 120190075Sobrien 1202117395SkanCurrently, GCC defines @code{__STDC__} unconditionally. This provides 1203117395Skangood results in practice. 120490075Sobrien 120590075SobrienProgrammers normally use conditionals on @code{__STDC__} to ask whether 120690075Sobrienit is safe to use certain features of ISO C, such as function 120790075Sobrienprototypes or ISO token concatenation. Since plain @command{gcc} supports 120890075Sobrienall the features of ISO C, the correct answer to these questions is 120990075Sobrien``yes''. 121090075Sobrien 121190075SobrienSome users try to use @code{__STDC__} to check for the availability of 121290075Sobriencertain library facilities. This is actually incorrect usage in an ISO 121390075SobrienC program, because the ISO C standard says that a conforming 121490075Sobrienfreestanding implementation should define @code{__STDC__} even though it 121590075Sobriendoes not have the library facilities. @samp{gcc -ansi -pedantic} is a 121690075Sobrienconforming freestanding implementation, and it is therefore required to 121790075Sobriendefine @code{__STDC__}, even though it does not come with an ISO C 121890075Sobrienlibrary. 121990075Sobrien 122090075SobrienSometimes people say that defining @code{__STDC__} in a compiler that 122190075Sobriendoes not completely conform to the ISO C standard somehow violates the 122290075Sobrienstandard. This is illogical. The standard is a standard for compilers 122390075Sobrienthat claim to support ISO C, such as @samp{gcc -ansi}---not for other 122490075Sobriencompilers such as plain @command{gcc}. Whatever the ISO C standard says 122590075Sobrienis relevant to the design of plain @command{gcc} without @option{-ansi} only 122690075Sobrienfor pragmatic reasons, not as a requirement. 122790075Sobrien 122890075SobrienGCC normally defines @code{__STDC__} to be 1, and in addition 122990075Sobriendefines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, 123090075Sobrienor a @option{-std} option for strict conformance to some version of ISO C@. 123190075SobrienOn some hosts, system include files use a different convention, where 123290075Sobrien@code{__STDC__} is normally 0, but is 1 if the user specifies strict 123390075Sobrienconformance to the C Standard. GCC follows the host convention when 123490075Sobrienprocessing system include files, but when processing user files it follows 123590075Sobrienthe usual GNU C convention. 123690075Sobrien 123790075Sobrien@item 123890075SobrienUndefining @code{__STDC__} in C++. 123990075Sobrien 124090075SobrienPrograms written to compile with C++-to-C translators get the 124190075Sobrienvalue of @code{__STDC__} that goes with the C compiler that is 124290075Sobriensubsequently used. These programs must test @code{__STDC__} 124390075Sobriento determine what kind of C preprocessor that compiler uses: 124490075Sobrienwhether they should concatenate tokens in the ISO C fashion 124590075Sobrienor in the traditional fashion. 124690075Sobrien 124790075SobrienThese programs work properly with GNU C++ if @code{__STDC__} is defined. 124890075SobrienThey would not work otherwise. 124990075Sobrien 125090075SobrienIn addition, many header files are written to provide prototypes in ISO 125190075SobrienC but not in traditional C@. Many of these header files can work without 125290075Sobrienchange in C++ provided @code{__STDC__} is defined. If @code{__STDC__} 125390075Sobrienis not defined, they will all fail, and will all need to be changed to 125490075Sobrientest explicitly for C++ as well. 125590075Sobrien 125690075Sobrien@item 125790075SobrienDeleting ``empty'' loops. 125890075Sobrien 125990075SobrienHistorically, GCC has not deleted ``empty'' loops under the 126090075Sobrienassumption that the most likely reason you would put one in a program is 126190075Sobriento have a delay, so deleting them will not make real programs run any 126290075Sobrienfaster. 126390075Sobrien 126490075SobrienHowever, the rationale here is that optimization of a nonempty loop 126590075Sobriencannot produce an empty one, which holds for C but is not always the 126690075Sobriencase for C++. 126790075Sobrien 126890075Sobrien@opindex funroll-loops 126990075SobrienMoreover, with @option{-funroll-loops} small ``empty'' loops are already 127090075Sobrienremoved, so the current behavior is both sub-optimal and inconsistent 127190075Sobrienand will change in the future. 127290075Sobrien 127390075Sobrien@item 127490075SobrienMaking side effects happen in the same order as in some other compiler. 127590075Sobrien 127690075Sobrien@cindex side effects, order of evaluation 127790075Sobrien@cindex order of evaluation, side effects 127890075SobrienIt is never safe to depend on the order of evaluation of side effects. 127990075SobrienFor example, a function call like this may very well behave differently 128090075Sobrienfrom one compiler to another: 128190075Sobrien 128290075Sobrien@example 128390075Sobrienvoid func (int, int); 128490075Sobrien 128590075Sobrienint i = 2; 128690075Sobrienfunc (i++, i++); 128790075Sobrien@end example 128890075Sobrien 128990075SobrienThere is no guarantee (in either the C or the C++ standard language 129090075Sobriendefinitions) that the increments will be evaluated in any particular 129190075Sobrienorder. Either increment might happen first. @code{func} might get the 129290075Sobrienarguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. 129390075Sobrien 129490075Sobrien@item 129590075SobrienNot allowing structures with volatile fields in registers. 129690075Sobrien 129790075SobrienStrictly speaking, there is no prohibition in the ISO C standard 129890075Sobrienagainst allowing structures with volatile fields in registers, but 129990075Sobrienit does not seem to make any sense and is probably not what you wanted 130090075Sobriento do. So the compiler will give an error message in this case. 130190075Sobrien 130290075Sobrien@item 130390075SobrienMaking certain warnings into errors by default. 130490075Sobrien 130590075SobrienSome ISO C testsuites report failure when the compiler does not produce 130690075Sobrienan error message for a certain program. 130790075Sobrien 130890075Sobrien@opindex pedantic-errors 130990075SobrienISO C requires a ``diagnostic'' message for certain kinds of invalid 131090075Sobrienprograms, but a warning is defined by GCC to count as a diagnostic. If 131190075SobrienGCC produces a warning but not an error, that is correct ISO C support. 131290075SobrienIf test suites call this ``failure'', they should be run with the GCC 131390075Sobrienoption @option{-pedantic-errors}, which will turn these warnings into 131490075Sobrienerrors. 131590075Sobrien 131690075Sobrien@end itemize 131790075Sobrien 131890075Sobrien@node Warnings and Errors 131990075Sobrien@section Warning Messages and Error Messages 132090075Sobrien 132190075Sobrien@cindex error messages 132290075Sobrien@cindex warnings vs errors 132390075Sobrien@cindex messages, warning and error 132490075SobrienThe GNU compiler can produce two kinds of diagnostics: errors and 132590075Sobrienwarnings. Each kind has a different purpose: 132690075Sobrien 132790075Sobrien@itemize @w{} 132890075Sobrien@item 132990075Sobrien@dfn{Errors} report problems that make it impossible to compile your 133090075Sobrienprogram. GCC reports errors with the source file name and line 133190075Sobriennumber where the problem is apparent. 133290075Sobrien 133390075Sobrien@item 133490075Sobrien@dfn{Warnings} report other unusual conditions in your code that 133590075Sobrien@emph{may} indicate a problem, although compilation can (and does) 133690075Sobrienproceed. Warning messages also report the source file name and line 133790075Sobriennumber, but include the text @samp{warning:} to distinguish them 133890075Sobrienfrom error messages. 133990075Sobrien@end itemize 134090075Sobrien 134190075SobrienWarnings may indicate danger points where you should check to make sure 134290075Sobrienthat your program really does what you intend; or the use of obsolete 134390075Sobrienfeatures; or the use of nonstandard features of GNU C or C++. Many 134490075Sobrienwarnings are issued only if you ask for them, with one of the @option{-W} 134590075Sobrienoptions (for instance, @option{-Wall} requests a variety of useful 134690075Sobrienwarnings). 134790075Sobrien 134890075Sobrien@opindex pedantic 134990075Sobrien@opindex pedantic-errors 135090075SobrienGCC always tries to compile your program if possible; it never 135190075Sobriengratuitously rejects a program whose meaning is clear merely because 135290075Sobrien(for instance) it fails to conform to a standard. In some cases, 135390075Sobrienhowever, the C and C++ standards specify that certain extensions are 135490075Sobrienforbidden, and a diagnostic @emph{must} be issued by a conforming 135590075Sobriencompiler. The @option{-pedantic} option tells GCC to issue warnings in 135690075Sobriensuch cases; @option{-pedantic-errors} says to make them errors instead. 135790075SobrienThis does not mean that @emph{all} non-ISO constructs get warnings 135890075Sobrienor errors. 135990075Sobrien 136090075Sobrien@xref{Warning Options,,Options to Request or Suppress Warnings}, for 136190075Sobrienmore detail on these and related command-line options. 1362