trouble.texi revision 119256
1141104Sharti@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 294589Sobrien@c 1999, 2000, 2001 Free Software Foundation, Inc. 394589Sobrien@c This is part of the GCC manual. 45814Sjkh@c For copying conditions, see the file gcc.texi. 51590Srgrimes 61590Srgrimes@node Trouble 71590Srgrimes@chapter Known Causes of Trouble with GCC 81590Srgrimes@cindex bugs, known 91590Srgrimes@cindex installation trouble 101590Srgrimes@cindex known causes of trouble 111590Srgrimes 121590SrgrimesThis section describes known problems that affect users of GCC@. Most 131590Srgrimesof these are not GCC bugs per se---if they were, we would fix them. 141590SrgrimesBut the result for a user may be like the result of a bug. 151590Srgrimes 161590SrgrimesSome of these problems are due to bugs in other software, some are 171590Srgrimesmissing features that are too much work to add, and some are places 181590Srgrimeswhere people's opinions differ as to what is best. 191590Srgrimes 201590Srgrimes@menu 211590Srgrimes* Actual Bugs:: Bugs we will fix later. 221590Srgrimes* Cross-Compiler Problems:: Common problems of cross compiling with GCC. 231590Srgrimes* Interoperation:: Problems using GCC with other compilers, 241590Srgrimes and with certain linkers, assemblers and debuggers. 251590Srgrimes* External Bugs:: Problems compiling certain programs. 261590Srgrimes* Incompatibilities:: GCC is incompatible with traditional C. 271590Srgrimes* Fixed Headers:: GCC uses corrected versions of system header files. 281590Srgrimes This is necessary, but doesn't always work smoothly. 291590Srgrimes* Standard Libraries:: GCC uses the system C library, which might not be 301590Srgrimes compliant with the ISO C standard. 311590Srgrimes* Disappointments:: Regrettable things we can't change, but not quite bugs. 321590Srgrimes* C++ Misunderstandings:: Common misunderstandings with GNU C++. 331590Srgrimes* Protoize Caveats:: Things to watch out for when using @code{protoize}. 341590Srgrimes* Non-bugs:: Things we think are right, but some others disagree. 351590Srgrimes* Warnings and Errors:: Which problems in your code get warnings, 361590Srgrimes and which get errors. 371590Srgrimes@end menu 3862833Swsanchez 3962833Swsanchez@node Actual Bugs 401590Srgrimes@section Actual Bugs We Haven't Fixed Yet 411590Srgrimes 4262833Swsanchez@itemize @bullet 4394587Sobrien@item 441590SrgrimesThe @code{fixincludes} script interacts badly with automounters; if the 451590Srgrimesdirectory of system header files is automounted, it tends to be 461590Srgrimesunmounted while @code{fixincludes} is running. This would seem to be a 471590Srgrimesbug in the automounter. We don't know any good way to work around it. 481590Srgrimes 491590Srgrimes@item 50144467ShartiThe @code{fixproto} script will sometimes add prototypes for the 511590Srgrimes@code{sigsetjmp} and @code{siglongjmp} functions that reference the 52144467Sharti@code{jmp_buf} type before that type is defined. To work around this, 53144467Shartiedit the offending file and place the typedef in front of the 54144467Shartiprototypes. 55144467Sharti 56144467Sharti@item 57144467Sharti@opindex pedantic-errors 58144467ShartiWhen @option{-pedantic-errors} is specified, GCC will incorrectly give 591590Srgrimesan error message when a function name is specified in an expression 60144467Shartiinvolving the comma operator. 61144467Sharti@end itemize 62144467Sharti 63144467Sharti@node Cross-Compiler Problems 64144467Sharti@section Cross-Compiler Problems 651590Srgrimes 66144467ShartiYou may run into problems with cross compilation on certain machines, 67144467Shartifor several reasons. 68144467Sharti 69144467Sharti@itemize @bullet 701590Srgrimes@item 71144467ShartiCross compilation can run into trouble for certain machines because 721590Srgrimessome target machines' assemblers require floating point numbers to be 73144467Shartiwritten as @emph{integer} constants in certain contexts. 741590Srgrimes 75144467ShartiThe compiler writes these integer constants by examining the floating 76144467Shartipoint value as an integer and printing that integer, because this is 77144467Shartisimple to write and independent of the details of the floating point 78144467Shartirepresentation. But this does not work if the compiler is running on 791590Srgrimesa different machine with an incompatible floating point format, or 80144467Shartieven a different byte-ordering. 81144467Sharti 82144467ShartiIn addition, correct constant folding of floating point values 831590Srgrimesrequires representing them in the target machine's format. 84144467Sharti(The C standard does not quite require this, but in practice 85144467Shartiit is the only way to win.) 86144467Sharti 871590SrgrimesIt is now possible to overcome these problems by defining macros such 88144467Shartias @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of 891590Srgrimeswork for each target machine. 90144467Sharti@xref{Cross-compilation,,Cross Compilation and Floating Point, 91146132Shartigccint, GNU Compiler Collection (GCC) Internals}. 92146132Sharti 93146132Sharti@item 94146132ShartiAt present, the program @file{mips-tfile} which adds debug 95146132Shartisupport to object files on MIPS systems does not work in a cross 96146132Sharticompile environment. 97146132Sharti@end itemize 98146132Sharti 99146132Sharti@node Interoperation 100146132Sharti@section Interoperation 101146132Sharti 1021590SrgrimesThis section lists various difficulties encountered in using GCC 1031590Srgrimestogether with other compilers or with the assemblers, linkers, 104144494Shartilibraries and debuggers on certain systems. 1051590Srgrimes 106141104Sharti@itemize @bullet 1071590Srgrimes@item 108107447SruOn many platforms, GCC supports a different ABI for C++ than do other 109104475Sphkcompilers, so the object files compiled by GCC cannot be used with object 110107447Srufiles generated by another C++ compiler. 1111590Srgrimes 112141104ShartiAn area where the difference is most apparent is name mangling. The use 113146160Sjmallettof different name mangling is intentional, to protect you from more subtle 11494506Scharnierproblems. 1155814SjkhCompilers differ as to many internal details of C++ implementation, 116144665Shartiincluding: how class instances are laid out, how multiple inheritance is 117202045Shartiimplemented, and how virtual function calls are handled. If the name 118202070Shartiencoding were made the same, your programs would link against libraries 1191590Srgrimesprovided from other compilers---but the programs would then crash when 1205814Sjkhrun. Incompatible libraries are then detected at link time, rather than 121141104Shartiat run time. 12280381Ssheldonh 12394506Scharnier@item 124141104ShartiOlder GDB versions sometimes fail to read the output of GCC version 125141104Sharti2. If you have trouble, get GDB version 4.4 or later. 126142457Sharti 127146056Sharti@item 1281590Srgrimes@cindex DBX 129141104ShartiDBX rejects some files produced by GCC, though it accepts similar 130141104Sharticonstructs in output from PCC@. Until someone can supply a coherent 1311590Srgrimesdescription of what is valid DBX input and what is not, there is 132141104Shartinothing I can do about these problems. You are on your own. 133141104Sharti 134146574Sharti@item 135146572ShartiThe GNU assembler (GAS) does not support PIC@. To generate PIC code, you 136141104Shartimust use some other assembler, such as @file{/bin/as}. 137146056Sharti 138141104Sharti@item 139141104ShartiOn some BSD systems, including some versions of Ultrix, use of profiling 140141104Sharticauses static variable destructors (currently used only in C++) not to 1411590Srgrimesbe run. 142202045Sharti 143146057Sharti@ignore 144146057Sharti@cindex @code{vfork}, for the Sun-4 1451590Srgrimes@item 146146057ShartiThere is a bug in @code{vfork} on the Sun-4 which causes the registers 147146057Shartiof the child process to clobber those of the parent. Because of this, 148146057Shartiprograms that call @code{vfork} are likely to lose when compiled 149146057Shartioptimized with GCC when the child code alters registers which contain 150146057ShartiC variables in the parent. This affects variables which are live in the 151146057Shartiparent across the call to @code{vfork}. 152146057Sharti 153146057ShartiIf you encounter this, you can work around the problem by declaring 154146057Shartivariables @code{volatile} in the function that calls @code{vfork}, until 155144483Shartithe problem goes away, or by not declaring them @code{register} and not 156144483Shartiusing @option{-O} for those source files. 157144483Sharti@end ignore 158144483Sharti 159144483Sharti@item 160144483ShartiOn some SGI systems, when you use @option{-lgl_s} as an option, 161144483Shartiit gets translated magically to @samp{-lgl_s -lX11_s -lc_s}. 162144483ShartiNaturally, this does not happen when you use GCC@. 163144483ShartiYou must specify all three options explicitly. 164144483Sharti 165144483Sharti@item 166144483ShartiOn a SPARC, GCC aligns all values of type @code{double} on an 8-byte 167144665Shartiboundary, and it expects every @code{double} to be so aligned. The Sun 168144483Sharticompiler usually gives @code{double} values 8-byte alignment, with one 169144483Shartiexception: function arguments of type @code{double} may not be aligned. 170144483Sharti 171144483ShartiAs a result, if a function compiled with Sun CC takes the address of an 172144483Shartiargument of type @code{double} and passes this pointer of type 173144483Sharti@code{double *} to a function compiled with GCC, dereferencing the 174144483Shartipointer may cause a fatal signal. 175144483Sharti 176144483ShartiOne way to solve this problem is to compile your entire program with GCC@. 177144483ShartiAnother solution is to modify the function that is compiled with 178144483ShartiSun CC to copy the argument into a local variable; local variables 179144483Shartiare always properly aligned. A third solution is to modify the function 180144483Shartithat uses the pointer to dereference it via the following function 181144483Sharti@code{access_double} instead of directly with @samp{*}: 182144483Sharti 183144483Sharti@smallexample 184144483Shartiinline double 185144483Shartiaccess_double (double *unaligned_ptr) 186144483Sharti@{ 187144483Sharti union d2i @{ double d; int i[2]; @}; 188144483Sharti 189144483Sharti union d2i *p = (union d2i *) unaligned_ptr; 190144483Sharti union d2i u; 191144483Sharti 192146061Sharti u.i[0] = p->i[0]; 193144483Sharti u.i[1] = p->i[1]; 194144483Sharti 195144483Sharti return u.d; 196144483Sharti@} 197144483Sharti@end smallexample 198144483Sharti 199144483Sharti@noindent 200144483ShartiStoring into the pointer can be done likewise with the same union. 201144483Sharti 202144483Sharti@item 203144483ShartiOn Solaris, the @code{malloc} function in the @file{libmalloc.a} library 204144483Shartimay allocate memory that is only 4 byte aligned. Since GCC on the 205144483ShartiSPARC assumes that doubles are 8 byte aligned, this may result in a 206146061Shartifatal signal if doubles are stored in memory allocated by the 207144483Sharti@file{libmalloc.a} library. 208144483Sharti 209144483ShartiThe solution is to not use the @file{libmalloc.a} library. Use instead 210144483Sharti@code{malloc} and related functions from @file{libc.a}; they do not have 211144483Shartithis problem. 212144483Sharti 213144483Sharti@item 214144483ShartiSun forgot to include a static version of @file{libdl.a} with some 215144483Shartiversions of SunOS (mainly 4.1). This results in undefined symbols when 216144483Shartilinking static binaries (that is, if you use @option{-static}). If you 217144483Shartisee undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen} 218144483Shartiwhen linking, compile and link against the file 219144483Sharti@file{mit/util/misc/dlsym.c} from the MIT version of X windows. 220144483Sharti 221144483Sharti@item 222144483ShartiThe 128-bit long double format that the SPARC port supports currently 223144483Shartiworks by using the architecturally defined quad-word floating point 224144483Shartiinstructions. Since there is no hardware that supports these 225144483Shartiinstructions they must be emulated by the operating system. Long 226144483Shartidoubles do not work in Sun OS versions 4.0.3 and earlier, because the 227144483Shartikernel emulator uses an obsolete and incompatible format. Long doubles 228144483Shartido not work in Sun OS version 4.1.1 due to a problem in a Sun library. 229144483ShartiLong doubles do work on Sun OS versions 4.1.2 and higher, but GCC 230144483Shartidoes not enable them by default. Long doubles appear to work in Sun OS 231144483Sharti5.x (Solaris 2.x). 232144483Sharti 233144483Sharti@item 234144483ShartiOn HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not 235144483Sharticompile GCC correctly. We do not yet know why. However, GCC 236144483Sharticompiled on earlier HP-UX versions works properly on HP-UX 9.01 and can 237144483Sharticompile itself properly on 9.01. 238144483Sharti 239144483Sharti@item 240144483ShartiOn the HP PA machine, ADB sometimes fails to work on functions compiled 241202045Shartiwith GCC@. Specifically, it fails to work on functions that use 242144483Sharti@code{alloca} or variable-size arrays. This is because GCC doesn't 243144483Shartigenerate HP-UX unwind descriptors for such functions. It may even be 244144483Shartiimpossible to generate them. 245144483Sharti 246144483Sharti@item 247144483ShartiDebugging (@option{-g}) is not supported on the HP PA machine, unless you use 248144483Shartithe preliminary GNU tools. 249144483Sharti 250144483Sharti@item 251144483ShartiTaking the address of a label may generate errors from the HP-UX 252144494ShartiPA assembler. GAS for the PA does not have this problem. 253144494Sharti 254144483Sharti@item 255144483ShartiUsing floating point parameters for indirect calls to static functions 256146061Shartiwill not work when using the HP assembler. There simply is no way for GCC 257146061Shartito specify what registers hold arguments for static functions when using 258144483Shartithe HP assembler. GAS for the PA does not have this problem. 259144483Sharti 260144483Sharti@item 261146061ShartiIn extremely rare cases involving some very large functions you may 262144483Shartireceive errors from the HP linker complaining about an out of bounds 263144494Shartiunconditional branch offset. This used to occur more often in previous 264144494Shartiversions of GCC, but is now exceptionally rare. If you should run 265144483Shartiinto it, you can work around by making your function smaller. 2668874Srgrimes 2671590Srgrimes@item 268144467ShartiGCC compiled code sometimes emits warnings from the HP-UX assembler of 269144467Shartithe form: 270144467Sharti 271144467Sharti@smallexample 2721590Srgrimes(warning) Use of GR3 when 27318730Ssteve frame >= 8192 may cause conflict. 27418730Ssteve@end smallexample 27518730Ssteve 27618730SsteveThese warnings are harmless and can be safely ignored. 277138232Sharti 2781590Srgrimes@item 2791590SrgrimesOn the IBM RS/6000, compiling code of the form 2801590Srgrimes 2811590Srgrimes@smallexample 2821590Srgrimesextern int foo; 2831590Srgrimes 284144467Sharti@dots{} foo @dots{} 2851590Srgrimes 2861590Srgrimesstatic int foo; 287144467Sharti@end smallexample 288144467Sharti 289144467Sharti@noindent 290144467Shartiwill cause the linker to report an undefined symbol @code{foo}. 291144467ShartiAlthough this behavior differs from most other systems, it is not a 292144467Shartibug because redefining an @code{extern} variable as @code{static} 2931590Srgrimesis undefined in ISO C@. 2941590Srgrimes 295144467Sharti@item 296146061ShartiIn extremely rare cases involving some very large functions you may 297144467Shartireceive errors from the AIX Assembler complaining about a displacement 298144467Shartithat is too large. If you should run into it, you can work around by 2991590Srgrimesmaking your function smaller. 3001590Srgrimes 301146140Sharti@item 302146140ShartiThe @file{libstdc++.a} library in GCC relies on the SVR4 dynamic 303146140Shartilinker semantics which merges global symbols between libraries and 304146140Shartiapplications, especially necessary for C++ streams functionality. 305146140ShartiThis is not the default behavior of AIX shared libraries and dynamic 306144656Shartilinking. @file{libstdc++.a} is built on AIX with ``runtime-linking'' 307138916Shartienabled so that symbol merging can occur. To utilize this feature, 308138916Shartithe application linked with @file{libstdc++.a} must include the 309144494Sharti@option{-Wl,-brtl} flag on the link line. G++ cannot impose this 310138916Shartibecause this option may interfere with the semantics of the user 311146061Shartiprogram and users may not always use @samp{g++} to link his or her 3121590Srgrimesapplication. Applications are not required to use the 313137572Sphk@option{-Wl,-brtl} flag on the link line---the rest of the 314104475Sphk@file{libstdc++.a} library which is not dependent on the symbol 315104475Sphkmerging semantics will continue to function correctly. 316104475Sphk 317146061Sharti@item 3181590SrgrimesAn application can interpose its own definition of functions for 3191590Srgrimesfunctions invoked by @file{libstdc++.a} with ``runtime-linking'' 3201590Srgrimesenabled on AIX. To accomplish this the application must be linked 321146061Shartiwith ``runtime-linking'' option and the functions explicitly must be 3221590Srgrimesexported by the application (@option{-Wl,-brtl,-bE:exportfile}). 323146061Sharti 3241590Srgrimes@item 3251590SrgrimesAIX on the RS/6000 provides support (NLS) for environments outside of 326186559Sobrienthe United States. Compilers and assemblers use NLS to support 3271590Srgrimeslocale-specific representations of various objects including 328186559Sobrienfloating-point numbers (@samp{.} vs @samp{,} for separating decimal 329137202Shartifractions). There have been problems reported where the library linked 330186559Sobrienwith GCC does not produce the same floating-point formats that the 33118730Ssteveassembler accepts. If you have this problem, set the @env{LANG} 3321590Srgrimesenvironment variable to @samp{C} or @samp{En_US}. 333137252Sharti 334137252Sharti@item 335137252Sharti@opindex fdollars-in-identifiers 3368874SrgrimesEven if you specify @option{-fdollars-in-identifiers}, 337138916Shartiyou cannot successfully use @samp{$} in identifiers on the RS/6000 due 338138916Shartito a restriction in the IBM assembler. GAS supports these 339138916Shartiidentifiers. 3401590Srgrimes 341144494Sharti@cindex VAX calling convention 3421590Srgrimes@cindex Ultrix calling convention 343144656Sharti@item 344144656Sharti@opindex fcall-saved 345144656ShartiOn Ultrix, the Fortran compiler expects registers 2 through 5 to be saved 3461590Srgrimesby function calls. However, the C compiler uses conventions compatible 347194217Sdeswith BSD Unix: registers 2 through 5 may be clobbered by function calls. 348137605Sharti 349137605ShartiGCC uses the same convention as the Ultrix C compiler. You can use 3501590Srgrimesthese options to produce code compatible with the Fortran compiler: 35118730Ssteve 3521590Srgrimes@smallexample 3531590Srgrimes-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 35418730Ssteve@end smallexample 3551590Srgrimes 35618730Ssteve@item 3571590SrgrimesOn the Alpha, you may get assembler errors about invalid syntax as a 3581590Srgrimesresult of floating point constants. This is due to a bug in the C 3591590Srgrimeslibrary functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid 36018730Sstevefloating point numbers, they sometimes print @samp{NaN}. 36118730Ssteve@end itemize 36218730Ssteve 36318730Ssteve@node External Bugs 36418730Ssteve@section Problems Compiling Certain Programs 36518730Ssteve 366103503Sjmallett@c prevent bad page break with this line 36718730SsteveCertain programs have problems compiling. 368138232Sharti 36918730Ssteve@itemize @bullet 37018730Ssteve@item 37118730SsteveParse errors may occur compiling X11 on a Decstation running Ultrix 4.2 37218730Sstevebecause of problems in DEC's versions of the X11 header files 37318730Ssteve@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding 37418730Ssteve@option{-I/usr/include/mit} to use the MIT versions of the header files, 37518730Ssteveor fixing the header files by adding this: 376103503Sjmallett 377103503Sjmallett@example 37818730Ssteve#ifdef __STDC__ 37992921Simp#define NeedFunctionPrototypes 0 38092921Simp#endif 38192921Simp@end example 38292921Simp 38392921Simp@item 384228157SfjoeOn various 386 Unix systems derived from System V, including SCO, ISC, 3851590Srgrimesand ESIX, you may get error messages about running out of virtual memory 386146132Shartiwhile compiling certain programs. 387146132Sharti 388146132ShartiYou can prevent this problem by linking GCC with the GNU malloc 389146155Sharti(which thus replaces the malloc that comes with the system). GNU malloc 390146155Shartiis available as a separate package, and also in the file 391146155Sharti@file{src/gmalloc.c} in the GNU Emacs 19 distribution. 392146155Sharti 393146155ShartiIf you have installed GNU malloc as a separate library package, use this 394146155Shartioption when you relink GCC: 395146155Sharti 396146155Sharti@example 397146155ShartiMALLOC=/usr/local/lib/libgmalloc.a 398146155Sharti@end example 399146155Sharti 400146155ShartiAlternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy 401146155Shartithe object file to @file{gmalloc.o} and use this option when you relink 402146155ShartiGCC: 403146155Sharti 404146155Sharti@example 405146155ShartiMALLOC=gmalloc.o 406146155Sharti@end example 407146155Sharti@end itemize 408146155Sharti 409146155Sharti@node Incompatibilities 410146155Sharti@section Incompatibilities of GCC 411146155Sharti@cindex incompatibilities of GCC 412146155Sharti@opindex traditional 413146155Sharti 414146155ShartiThere are several noteworthy incompatibilities between GNU C and K&R 415146155Sharti(non-ISO) versions of C@. 416183465Sache 417183465Sache@itemize @bullet 418183465Sache@cindex string constants 419183465Sache@cindex read-only strings 420183465Sache@cindex shared strings 421183465Sache@item 422146155ShartiGCC normally makes string constants read-only. If several 423146155Shartiidentical-looking string constants are used, GCC stores only one 424146155Sharticopy of the string. 425146155Sharti 426146155Sharti@cindex @code{mktemp}, and constant strings 427146155ShartiOne consequence is that you cannot call @code{mktemp} with a string 428146155Sharticonstant argument. The function @code{mktemp} always alters the 429146155Shartistring its argument points to. 430146155Sharti 431146155Sharti@cindex @code{sscanf}, and constant strings 432146155Sharti@cindex @code{fscanf}, and constant strings 433146155Sharti@cindex @code{scanf}, and constant strings 434146155ShartiAnother consequence is that @code{sscanf} does not work on some systems 435146155Shartiwhen passed a string constant as its format control string or input. 436146155ShartiThis is because @code{sscanf} incorrectly tries to write into the string 437146155Sharticonstant. Likewise @code{fscanf} and @code{scanf}. 438146155Sharti 439146155Sharti@opindex fwritable-strings 440146155ShartiThe best solution to these problems is to change the program to use 441146155Sharti@code{char}-array variables with initialization strings for these 442146155Shartipurposes instead of string constants. But if this is not possible, 443146155Shartiyou can use the @option{-fwritable-strings} flag, which directs GCC 444146155Shartito handle string constants the same way most C compilers do. 445146155Sharti 446146155Sharti@item 447146155Sharti@code{-2147483648} is positive. 448146155Sharti 449146155ShartiThis is because 2147483648 cannot fit in the type @code{int}, so 450146155Sharti(following the ISO C rules) its data type is @code{unsigned long int}. 451146155ShartiNegating this value yields 2147483648 again. 452146155Sharti 453146155Sharti@item 454146155ShartiGCC does not substitute macro arguments when they appear inside of 455146155Shartistring constants. For example, the following macro in GCC 456146155Sharti 457146155Sharti@example 458146155Sharti#define foo(a) "a" 459146155Sharti@end example 460146155Sharti 461146155Sharti@noindent 462146155Shartiwill produce output @code{"a"} regardless of what the argument @var{a} is. 463146155Sharti 464146155Sharti@cindex @code{setjmp} incompatibilities 465146155Sharti@cindex @code{longjmp} incompatibilities 466146155Sharti@item 467146155ShartiWhen you use @code{setjmp} and @code{longjmp}, the only automatic 468146155Shartivariables guaranteed to remain valid are those declared 469146155Sharti@code{volatile}. This is a consequence of automatic register 470146155Shartiallocation. Consider this function: 471146155Sharti 472146155Sharti@example 473146155Shartijmp_buf j; 474146155Sharti 475146155Shartifoo () 476146155Sharti@{ 477146155Sharti int a, b; 478146155Sharti 479146155Sharti a = fun1 (); 480146155Sharti if (setjmp (j)) 481146155Sharti return a; 482146144Sharti 483146144Sharti a = fun2 (); 484146144Sharti /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ 485146144Sharti return a + fun3 (); 486146144Sharti@} 487144467Sharti@end example 488146144Sharti 489146144ShartiHere @code{a} may or may not be restored to its first value when the 490201225Sed@code{longjmp} occurs. If @code{a} is allocated in a register, then 491146144Shartiits first value is restored; otherwise, it keeps the last value stored 492146144Shartiin it. 493146144Sharti 494146144Sharti@opindex W 495146144ShartiIf you use the @option{-W} option with the @option{-O} option, you will 496146144Shartiget a warning when GCC thinks such a problem might be possible. 497146144Sharti 498146144Sharti@item 499146144ShartiPrograms that use preprocessing directives in the middle of macro 500146144Shartiarguments do not work with GCC@. For example, a program like this 501146144Shartiwill not work: 502146144Sharti 503146144Sharti@example 504146144Sharti@group 505146144Shartifoobar ( 506146144Sharti#define luser 507146144Sharti hack) 508146131Sharti@end group 509146130Sharti@end example 510146130Sharti 511146130ShartiISO C does not permit such a construct. 512146130Sharti 513146130Sharti@item 514146130ShartiK&R compilers allow comments to cross over an inclusion boundary 515146130Sharti(i.e.@: started in an include file and ended in the including file). I think 516146130Shartithis would be quite ugly and can't imagine it could be needed. 517146130Sharti 518146130Sharti@cindex external declaration scope 519146131Sharti@cindex scope of external declarations 520146131Sharti@cindex declaration scope 521146131Sharti@item 522146131ShartiDeclarations of external variables and functions within a block apply 523146131Shartionly to the block containing the declaration. In other words, they 524146131Shartihave the same scope as any other declaration in the same place. 525146131Sharti 526146131ShartiIn some other C compilers, a @code{extern} declaration affects all the 527146131Shartirest of the file even if it happens within a block. 528146131Sharti 529146131Sharti@item 530146131ShartiIn traditional C, you can combine @code{long}, etc., with a typedef name, 531146130Shartias shown here: 532146130Sharti 533146130Sharti@example 534146130Shartitypedef int foo; 535146130Shartitypedef long foo bar; 536146130Sharti@end example 537137605Sharti 538144467ShartiIn ISO C, this is not allowed: @code{long} and other type modifiers 539144467Shartirequire an explicit @code{int}. 540137605Sharti 541137605Sharti@cindex typedef names as function parameters 542137605Sharti@item 543137605ShartiPCC allows typedef names to be used as function parameters. 544137605Sharti 545137605Sharti@item 546137605ShartiTraditional C allows the following erroneous pair of declarations to 547137605Shartiappear together in a given scope: 548144467Sharti 5491590Srgrimes@example 550137252Shartitypedef int foo; 5511590Srgrimestypedef foo foo; 5521590Srgrimes@end example 5531590Srgrimes 5541590Srgrimes@item 5551590SrgrimesGCC treats all characters of identifiers as significant. According to 5561590SrgrimesK&R-1 (2.2), ``No more than the first eight characters are significant, 557104696Sjmallettalthough more may be used.''. Also according to K&R-1 (2.2), ``An 5581590Srgrimesidentifier is a sequence of letters and digits; the first character must 559144741Shartibe a letter. The underscore _ counts as a letter.'', but GCC also 560144467Shartiallows dollar signs in identifiers. 561144467Sharti 5628874Srgrimes@cindex whitespace 563144467Sharti@item 564144467ShartiPCC allows whitespace in the middle of compound assignment operators 565144467Shartisuch as @samp{+=}. GCC, following the ISO standard, does not 566137605Shartiallow this. 567144467Sharti 568144741Sharti@cindex apostrophes 569144741Sharti@cindex ' 570144741Sharti@item 571144741ShartiGCC complains about unterminated character constants inside of 572144741Shartipreprocessing conditionals that fail. Some programs have English 5731590Srgrimescomments enclosed in conditionals that are guaranteed to fail; if these 574144467Sharticomments contain apostrophes, GCC will probably report an error. For 575144467Shartiexample, this code would produce an error: 576144467Sharti 577144467Sharti@example 578144467Sharti#if 0 579144467ShartiYou can't expect this to work. 580144467Sharti#endif 581144467Sharti@end example 582144657Sharti 583144467ShartiThe best solution to such a problem is to put the text into an actual 584144467ShartiC comment delimited by @samp{/*@dots{}*/}. 5858874Srgrimes 586144467Sharti@item 587144467ShartiMany user programs contain the declaration @samp{long time ();}. In the 588144467Shartipast, the system header files on many systems did not actually declare 589144467Sharti@code{time}, so it did not matter what type your program declared it to 590144467Shartireturn. But in systems with ISO C headers, @code{time} is declared to 591144467Shartireturn @code{time_t}, and if that is not the same as @code{long}, then 5928874Srgrimes@samp{long time ();} is erroneous. 593144467Sharti 594144467ShartiThe solution is to change your program to use appropriate system headers 595144467Sharti(@code{<time.h>} on systems with ISO C headers) and not to declare 596144467Sharti@code{time} if the system header files declare it, or failing that to 597144467Shartiuse @code{time_t} as the return type of @code{time}. 598144467Sharti 599144467Sharti@cindex @code{float} as function value type 600144467Sharti@item 601144467ShartiWhen compiling functions that return @code{float}, PCC converts it to 602144467Shartia double. GCC actually returns a @code{float}. If you are concerned 603144467Shartiwith PCC compatibility, you should declare your functions to return 6041590Srgrimes@code{double}; you might as well say what you mean. 605144467Sharti 606144467Sharti@cindex structures 607144467Sharti@cindex unions 6081590Srgrimes@item 609144467ShartiWhen compiling functions that return structures or unions, GCC 61018730Ssteveoutput code normally uses a method different from that used on most 611144467Shartiversions of Unix. As a result, code compiled with GCC cannot call 612144741Shartia structure-returning function compiled with PCC, and vice versa. 613144741Sharti 614144741ShartiThe method used by GCC is as follows: a structure or union which is 615144741Sharti1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union 616144741Shartiwith any other size is stored into an address supplied by the caller 6171590Srgrimes(usually in a special, fixed register, but on some machines it is passed 618144467Shartion the stack). The machine-description macros @code{STRUCT_VALUE} and 619144467Sharti@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address. 620144467Sharti 621144467ShartiBy contrast, PCC on most target machines returns structures and unions 6221590Srgrimesof any size by copying the data into an area of static storage, and then 6231590Srgrimesreturning the address of that storage as if it were a pointer value. 624144467ShartiThe caller must copy the data from that memory area to the place where 6251590Srgrimesthe value is wanted. GCC does not use this method because it is 6261590Srgrimesslower and nonreentrant. 6271590Srgrimes 6281590SrgrimesOn some newer machines, PCC uses a reentrant convention for all 6291590Srgrimesstructure and union returning. GCC on most of these machines uses a 6301590Srgrimescompatible convention when returning structures and unions in memory, 6311590Srgrimesbut still returns small structures and unions in registers. 6321590Srgrimes 6331590Srgrimes@opindex fpcc-struct-return 6341590SrgrimesYou can tell GCC to use a compatible convention for all structure and 6351590Srgrimesunion returning with the option @option{-fpcc-struct-return}. 63694594Sobrien 637142993Sharti@cindex preprocessing tokens 6381590Srgrimes@cindex preprocessing numbers 6391590Srgrimes@item 6401590SrgrimesGCC complains about program fragments such as @samp{0x74ae-0x4000} 6411590Srgrimeswhich appear to be two hexadecimal constants separated by the minus 6421590Srgrimesoperator. Actually, this string is a single @dfn{preprocessing token}. 6431590SrgrimesEach such token must correspond to one token in C@. Since this does not, 6441590SrgrimesGCC prints an error message. Although it may appear obvious that what 6451590Srgrimesis meant is an operator and two values, the ISO C standard specifically 6461590Srgrimesrequires that this be treated as erroneous. 6471590Srgrimes 6481590SrgrimesA @dfn{preprocessing token} is a @dfn{preprocessing number} if it 6491590Srgrimesbegins with a digit and is followed by letters, underscores, digits, 650228157Sfjoeperiods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, 6511590Srgrimes@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89 652144467Shartimode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot 653141258Shartiappear in preprocessing numbers.) 654141258Sharti 655144467ShartiTo make the above program fragment valid, place whitespace in front of 656141258Shartithe minus sign. This whitespace will end the preprocessing number. 657144467Sharti@end itemize 658141258Sharti 659141258Sharti@node Fixed Headers 660144467Sharti@section Fixed Header Files 661228157Sfjoe 6621590SrgrimesGCC needs to install corrected versions of some system header files. 663144467ShartiThis is because most target systems have some header files that won't 6641590Srgrimeswork with GCC unless they are changed. Some have bugs, some are 665144467Shartiincompatible with ISO C, and some depend on special features of other 666144467Sharticompilers. 667144467Sharti 668144467ShartiInstalling GCC automatically creates and installs the fixed header 6691590Srgrimesfiles, by running a program called @code{fixincludes} (or for certain 670144467Shartitargets an alternative such as @code{fixinc.svr4}). Normally, you 671144467Shartidon't need to pay attention to this. But there are cases where it 672144467Shartidoesn't do the right thing automatically. 673144467Sharti 674228157Sfjoe@itemize @bullet 675228157Sfjoe@item 676228157SfjoeIf you update the system's header files, such as by installing a new 677228157Sfjoesystem version, the fixed header files of GCC are not automatically 678228157Sfjoeupdated. The easiest way to update them is to reinstall GCC@. (If 679228157Sfjoeyou want to be clever, look in the makefile and you can find a 680228157Sfjoeshortcut.) 681228157Sfjoe 682228157Sfjoe@item 683228157SfjoeOn some systems, in particular SunOS 4, header file directories contain 684228157Sfjoemachine-specific symbolic links in certain places. This makes it 685142457Shartipossible to share most of the header files among hosts running the 686144467Shartisame version of SunOS 4 on different machine models. 687144467Sharti 688144467ShartiThe programs that fix the header files do not understand this special 689144467Shartiway of using symbolic links; therefore, the directory of fixed header 690144467Shartifiles is good only for the machine model used to build it. 691144467Sharti 692132839ShartiIn SunOS 4, only programs that look inside the kernel will notice the 693144467Shartidifference between machine models. Therefore, for most purposes, you 694144467Shartineed not be concerned about this. 695144467Sharti 696132839ShartiIt is possible to make separate sets of fixed header files for the 697144467Shartidifferent machine models, and arrange a structure of symbolic links so 698144467Shartias to use the proper set, but you'll have to do this by hand. 699144467Sharti 700132839Sharti@item 701144467ShartiOn Lynxos, GCC by default does not fix the header files. This is 702144467Shartibecause bugs in the shell cause the @code{fixincludes} script to fail. 703144467Sharti 704144467ShartiThis means you will encounter problems due to bugs in the system header 705144467Shartifiles. It may be no comfort that they aren't GCC's fault, but it 706144467Shartidoes mean that there's nothing for us to do about them. 707144467Sharti@end itemize 708228157Sfjoe 709144467Sharti@node Standard Libraries 710144467Sharti@section Standard Libraries 711144467Sharti 712144467Sharti@opindex Wall 713144467ShartiGCC by itself attempts to be a conforming freestanding implementation. 7141590Srgrimes@xref{Standards,,Language Standards Supported by GCC}, for details of 7151590Srgrimeswhat this means. Beyond the library facilities required of such an 716144467Shartiimplementation, the rest of the C library is supplied by the vendor of 717144467Shartithe operating system. If that C library doesn't conform to the C 7181590Srgrimesstandards, then your programs might get warnings (especially when using 719228157Sfjoe@option{-Wall}) that you don't expect. 720228157Sfjoe 721228157SfjoeFor example, the @code{sprintf} function on SunOS 4.1.3 returns 722228157Sfjoe@code{char *} while the C standard says that @code{sprintf} returns an 723228157Sfjoe@code{int}. The @code{fixincludes} program could make the prototype for 724228157Sfjoethis function match the Standard, but that would be wrong, since the 725228157Sfjoefunction will still return @code{char *}. 726228157Sfjoe 727228157SfjoeIf you need a Standard compliant library, then you need to find one, as 728228157SfjoeGCC does not provide one. The GNU C library (called @code{glibc}) 729144467Shartiprovides ISO C, POSIX, BSD, SystemV and X/Open compatibility for 730144467ShartiGNU/Linux and HURD-based GNU systems; no recent version of it supports 7311590Srgrimesother systems, though some very old versions did. Version 2.2 of the 73218730SsteveGNU C library includes nearly complete C99 support. You could also ask 7331590Srgrimesyour operating system vendor if newer libraries are available. 734144467Sharti 7351590Srgrimes@node Disappointments 736144467Sharti@section Disappointments and Misunderstandings 737144467Sharti 738144467ShartiThese problems are perhaps regrettable, but we don't know any practical 739144467Shartiway around them. 740144467Sharti 741144467Sharti@itemize @bullet 742144467Sharti@item 743144467ShartiCertain local variables aren't recognized by debuggers when you compile 744144467Shartiwith optimization. 745144467Sharti 746144467ShartiThis occurs because sometimes GCC optimizes the variable out of 747144467Shartiexistence. There is no way to tell the debugger how to compute the 748144467Shartivalue such a variable ``would have had'', and it is not clear that would 749144467Shartibe desirable anyway. So GCC simply does not mention the eliminated 750144467Shartivariable when it writes debugging information. 751144467Sharti 752144467ShartiYou have to expect a certain amount of disagreement between the 753144467Shartiexecutable and your source code, when you use optimization. 754144467Sharti 755144467Sharti@cindex conflicting types 756144467Sharti@cindex scope of declaration 757144467Sharti@item 758144467ShartiUsers often think it is a bug when GCC reports an error for code 759144657Shartilike this: 760144467Sharti 761144467Sharti@example 762144467Shartiint foo (struct mumble *); 763144467Sharti 764144467Shartistruct mumble @{ @dots{} @}; 765144467Sharti 766144467Shartiint foo (struct mumble *x) 767144467Sharti@{ @dots{} @} 768144467Sharti@end example 769144467Sharti 770144467ShartiThis code really is erroneous, because the scope of @code{struct 771144467Shartimumble} in the prototype is limited to the argument list containing it. 772144467ShartiIt does not refer to the @code{struct mumble} defined with file scope 773144467Shartiimmediately below---they are two unrelated types with similar names in 774144467Shartidifferent scopes. 775144467Sharti 776144467ShartiBut in the definition of @code{foo}, the file-scope type is used 777144467Shartibecause that is available to be inherited. Thus, the definition and 778144467Shartithe prototype do not match, and you get an error. 779144467Sharti 780144467ShartiThis behavior may seem silly, but it's what the ISO standard specifies. 781144467ShartiIt is easy enough for you to make your code work by moving the 782144467Shartidefinition of @code{struct mumble} above the prototype. It's not worth 783144467Shartibeing incompatible with ISO C just to avoid an error for the example 784144467Shartishown above. 785144467Sharti 786144467Sharti@item 787144467ShartiAccesses to bit-fields even in volatile objects works by accessing larger 788144467Shartiobjects, such as a byte or a word. You cannot rely on what size of 789144467Shartiobject is accessed in order to read or write the bit-field; it may even 790144467Shartivary for a given bit-field according to the precise usage. 791144467Sharti 792144467ShartiIf you care about controlling the amount of memory that is accessed, use 793144467Shartivolatile but do not use bit-fields. 794144467Sharti 7951590Srgrimes@item 796144467ShartiGCC comes with shell scripts to fix certain known problems in system 797144467Shartiheader files. They install corrected copies of various header files in 798144467Shartia special directory where only GCC will normally look for them. The 7991590Srgrimesscripts adapt to various systems by searching all the system header 800144467Shartifiles for the problem cases that we know about. 8011590Srgrimes 80218730SsteveIf new system header files are installed, nothing automatically arranges 8031590Srgrimesto update the corrected header files. You will have to reinstall GCC 8041590Srgrimesto fix the new header files. More specifically, go to the build 805144467Shartidirectory and delete the files @file{stmp-fixinc} and 8061590Srgrimes@file{stmp-headers}, and the subdirectory @code{include}; then do 807144467Sharti@samp{make install} again. 808144467Sharti 8091590Srgrimes@item 810144467Sharti@cindex floating point precision 8111590SrgrimesOn 68000 and x86 systems, for instance, you can get paradoxical results 8121590Srgrimesif you test the precise values of floating point numbers. For example, 813144467Shartiyou can find that a floating point value which is not a NaN is not equal 81418730Ssteveto itself. This results from the fact that the floating point registers 81518730Sstevehold a few more bits of precision than fit in a @code{double} in memory. 81618730SsteveCompiled code moves values between memory and floating point registers 81718730Ssteveat its convenience, and moving them into memory truncates them. 81818730Ssteve 81918730Ssteve@opindex ffloat-store 82018730SsteveYou can partially avoid this problem by using the @option{-ffloat-store} 821104696Sjmallettoption (@pxref{Optimize Options}). 82218730Ssteve 823138232Sharti@item 824144467ShartiOn AIX and other platforms without weak symbol support, templates 825137202Shartineed to be instantiated explicitly and symbols for static members 826144467Shartiof templates will not be generated. 82718730Ssteve 828144467Sharti@item 829144467ShartiOn AIX, GCC scans object files and library archives for static 830144467Sharticonstructors and destructors when linking an application before the 831144467Shartilinker prunes unreferenced symbols. This is necessary to prevent the 832144467ShartiAIX linker from mistakenly assuming that static constructor or 833144467Shartidestructor are unused and removing them before the scanning can occur. 834144467ShartiAll static constructors and destructors found will be referenced even 835144467Shartithough the modules in which they occur may not be used by the program. 83618730SsteveThis may lead to both increased executable size and unexpected symbol 83718730Sstevereferences. 83818730Ssteve@end itemize 839144467Sharti 8401590Srgrimes@node C++ Misunderstandings 8411590Srgrimes@section Common Misunderstandings with GNU C++ 8421590Srgrimes 8431590Srgrimes@cindex misunderstandings in C++ 8441590Srgrimes@cindex surprises in C++ 8451590Srgrimes@cindex C++ misunderstandings 8461590SrgrimesC++ is a complex language and an evolving one, and its standard 8471590Srgrimesdefinition (the ISO C++ standard) was only recently completed. As a 8481590Srgrimesresult, your C++ compiler may occasionally surprise you, even when its 8491590Srgrimesbehavior is correct. This section discusses some areas that frequently 8501590Srgrimesgive rise to questions of this sort. 8511590Srgrimes 8521590Srgrimes@menu 8531590Srgrimes* Static Definitions:: Static member declarations are not definitions 854186279Sfjoe* Temporaries:: Temporaries may vanish before you expect 8551590Srgrimes* Copy Assignment:: Copy Assignment operators copy virtual bases twice 8561590Srgrimes@end menu 8571590Srgrimes 858104696Sjmallett@node Static Definitions 8591590Srgrimes@subsection Declare @emph{and} Define Static Members 860144467Sharti 861144467Sharti@cindex C++ static data, declaring and defining 8621590Srgrimes@cindex static data in C++, declaring and defining 863146133Sharti@cindex declaring static data in C++ 864146133Sharti@cindex defining static data in C++ 865146133ShartiWhen a class has static data members, it is not enough to @emph{declare} 866144467Shartithe static member; you must also @emph{define} it. For example: 867144467Sharti 868146133Sharti@example 869146133Sharticlass Foo 870146133Sharti@{ 871146133Sharti @dots{} 872146133Sharti void method(); 873144467Sharti static int bar; 874146133Sharti@}; 875146133Sharti@end example 876146133Sharti 877146133ShartiThis declaration only establishes that the class @code{Foo} has an 878146133Sharti@code{int} named @code{Foo::bar}, and a member function named 879146133Sharti@code{Foo::method}. But you still need to define @emph{both} 880146133Sharti@code{method} and @code{bar} elsewhere. According to the ISO 881146133Shartistandard, you must supply an initializer in one (and only one) source 882146133Shartifile, such as: 883146133Sharti 884146133Sharti@example 885146133Shartiint Foo::bar = 0; 886146133Sharti@end example 887146133Sharti 888146133ShartiOther C++ compilers may not correctly implement the standard behavior. 889146133ShartiAs a result, when you switch to @command{g++} from one of these compilers, 890146133Shartiyou may discover that a program that appeared to work correctly in fact 891146133Shartidoes not conform to the standard: @command{g++} reports as undefined 892146133Shartisymbols any static data members that lack definitions. 893146133Sharti 8948874Srgrimes@node Temporaries 895146133Sharti@subsection Temporaries May Vanish Before You Expect 896146133Sharti 897146133Sharti@cindex temporaries, lifetime of 898146133Sharti@cindex portions of temporary objects, pointers to 899146133ShartiIt is dangerous to use pointers or references to @emph{portions} of a 900146133Shartitemporary object. The compiler may very well delete the object before 901146133Shartiyou expect it to, leaving a pointer to garbage. The most common place 902146133Shartiwhere this problem crops up is in classes like string classes, 903146133Shartiespecially ones that define a conversion function to type @code{char *} 904146133Shartior @code{const char *}---which is one reason why the standard 905146133Sharti@code{string} class requires you to call the @code{c_str} member 906146133Shartifunction. However, any class that returns a pointer to some internal 907146133Shartistructure is potentially subject to this problem. 908146133Sharti 909146133ShartiFor example, a program may use a function @code{strfunc} that returns 910146133Sharti@code{string} objects, and another function @code{charfunc} that 911146133Shartioperates on pointers to @code{char}: 912146133Sharti 913146133Sharti@example 914146133Shartistring strfunc (); 915146133Shartivoid charfunc (const char *); 916146133Sharti 917146133Shartivoid 918146133Shartif () 919146133Sharti@{ 9201590Srgrimes const char *p = strfunc().c_str(); 921144467Sharti @dots{} 922144467Sharti charfunc (p); 923144467Sharti @dots{} 924144467Sharti charfunc (p); 9251590Srgrimes@} 9261590Srgrimes@end example 927146133Sharti 928146133Sharti@noindent 929146133ShartiIn this situation, it may seem reasonable to save a pointer to the C 930144467Shartistring returned by the @code{c_str} member function and use that rather 931146133Shartithan call @code{c_str} repeatedly. However, the temporary string 932146133Sharticreated by the call to @code{strfunc} is destroyed after @code{p} is 933146133Shartiinitialized, at which point @code{p} is left pointing to freed memory. 934146133Sharti 935146133ShartiCode like this may run successfully under some other compilers, 936146133Shartiparticularly obsolete cfront-based compilers that delete temporaries 937146133Shartialong with normal local variables. However, the GNU C++ behavior is 938146133Shartistandard-conforming, so if your program depends on late destruction of 939146133Shartitemporaries it is not portable. 940146133Sharti 941146133ShartiThe safe way to write such code is to give the temporary a name, which 942146133Shartiforces it to remain until the end of the scope of the name. For 943146133Shartiexample: 944146133Sharti 945146133Sharti@example 9461590Srgrimesstring& tmp = strfunc (); 947144665Sharticharfunc (tmp.c_str ()); 948144665Sharti@end example 949146133Sharti 950146133Sharti@node Copy Assignment 951146133Sharti@subsection Implicit Copy-Assignment for Virtual Bases 952146133Sharti 953146133ShartiWhen a base class is virtual, only one subobject of the base class 954146133Shartibelongs to each full object. Also, the constructors and destructors are 955146133Shartiinvoked only once, and called from the most-derived class. However, such 956146133Shartiobjects behave unspecified when being assigned. For example: 957231544Sfjoe 958231544Sfjoe@example 959146133Shartistruct Base@{ 960146133Sharti char *name; 961144467Sharti Base(char *n) : name(strdup(n))@{@} 962144467Sharti Base& operator= (const Base& other)@{ 963144467Sharti free (name); 964144467Sharti name = strdup (other.name); 965231544Sfjoe @} 966231544Sfjoe@}; 967146133Sharti 968146133Shartistruct A:virtual Base@{ 969231544Sfjoe int val; 970144467Sharti A():Base("A")@{@} 971144467Sharti@}; 972144467Sharti 973144467Shartistruct B:virtual Base@{ 974144467Sharti int bval; 975144467Sharti B():Base("B")@{@} 976144467Sharti@}; 977146133Sharti 978146133Shartistruct Derived:public A, public B@{ 979146133Sharti Derived():Base("Derived")@{@} 980146133Sharti@}; 981144467Sharti 982146133Shartivoid func(Derived &d1, Derived &d2) 983146133Sharti@{ 984146133Sharti d1 = d2; 985146133Sharti@} 986146133Sharti@end example 987146133Sharti 988146133ShartiThe C++ standard specifies that @samp{Base::Base} is only called once 989146133Shartiwhen constructing or copy-constructing a Derived object. It is 990146133Shartiunspecified whether @samp{Base::operator=} is called more than once when 991146133Shartithe implicit copy-assignment for Derived objects is invoked (as it is 992146133Shartiinside @samp{func} in the example). 993146133Sharti 994146133Shartig++ implements the ``intuitive'' algorithm for copy-assignment: assign all 995146133Shartidirect bases, then assign all members. In that algorithm, the virtual 996146133Shartibase subobject can be encountered more than once. In the example, copying 997146133Shartiproceeds in the following order: @samp{val}, @samp{name} (via 998146133Sharti@code{strdup}), @samp{bval}, and @samp{name} again. 999146133Sharti 1000146133ShartiIf application code relies on copy-assignment, a user-defined 1001146133Sharticopy-assignment operator removes any uncertainties. With such an 1002146133Shartioperator, the application can define whether and how the virtual base 1003146133Shartisubobject is assigned. 1004146133Sharti 1005146133Sharti@node Protoize Caveats 1006146133Sharti@section Caveats of using @command{protoize} 1007146133Sharti 1008146133ShartiThe conversion programs @command{protoize} and @command{unprotoize} can 1009146133Shartisometimes change a source file in a way that won't work unless you 1010231544Sfjoerearrange it. 1011231544Sfjoe 1012146133Sharti@itemize @bullet 1013146133Sharti@item 1014146133Sharti@command{protoize} can insert references to a type name or type tag before 1015146133Shartithe definition, or in a file where they are not defined. 1016146133Sharti 1017146133ShartiIf this happens, compiler error messages should show you where the new 1018146133Shartireferences are, so fixing the file by hand is straightforward. 1019146133Sharti 1020146133Sharti@item 1021146133ShartiThere are some C constructs which @command{protoize} cannot figure out. 1022146133ShartiFor example, it can't determine argument types for declaring a 1023146133Shartipointer-to-function variable; this you must do by hand. @command{protoize} 1024146133Shartiinserts a comment containing @samp{???} each time it finds such a 1025146133Shartivariable; so you can find all such variables by searching for this 1026146133Shartistring. ISO C does not require declaring the argument types of 1027146133Shartipointer-to-function types. 1028146133Sharti 1029146133Sharti@item 1030144467ShartiUsing @command{unprotoize} can easily introduce bugs. If the program 1031144467Shartirelied on prototypes to bring about conversion of arguments, these 1032144467Sharticonversions will not take place in the program without prototypes. 1033144467ShartiOne case in which you can be sure @command{unprotoize} is safe is when 1034146133Shartiyou are removing prototypes that were made with @command{protoize}; if 1035231544Sfjoethe program worked before without any prototypes, it will work again 1036231544Sfjoewithout them. 1037146133Sharti 1038144467Sharti@opindex Wconversion 1039146133ShartiYou can find all the places where this problem might occur by compiling 1040146133Shartithe program with the @option{-Wconversion} option. It prints a warning 1041146133Shartiwhenever an argument is converted. 1042146133Sharti 10431590Srgrimes@item 1044146133ShartiBoth conversion programs can be confused if there are macro calls in and 1045146133Shartiaround the text to be converted. In other words, the standard syntax 1046146133Shartifor a declaration or definition must not result from expanding a macro. 1047146133ShartiThis problem is inherent in the design of C and cannot be fixed. If 1048146133Shartionly a few functions have confusing macro calls, you can easily convert 1049146133Shartithem manually. 1050146133Sharti 1051146133Sharti@item 1052146133Sharti@command{protoize} cannot get the argument types for a function whose 1053146133Shartidefinition was not actually compiled due to preprocessing conditionals. 1054144467ShartiWhen this happens, @command{protoize} changes nothing in regard to such 1055146133Shartia function. @command{protoize} tries to detect such instances and warn 1056144467Shartiabout them. 10571590Srgrimes 1058146133ShartiYou can generally work around this problem by using @command{protoize} step 1059146133Shartiby step, each time specifying a different set of @option{-D} options for 1060146133Sharticompilation, until all of the functions have been converted. There is 1061146133Shartino automatic way to verify that you have got them all, however. 1062146133Sharti 1063231544Sfjoe@item 1064231544SfjoeConfusion may result if there is an occasion to convert a function 1065146133Shartideclaration or definition in a region of source code where there is more 1066146133Shartithan one formal parameter list present. Thus, attempts to convert code 1067144467Sharticontaining multiple (conditionally compiled) versions of a single 1068146133Shartifunction header (in the same vicinity) may not produce the desired (or 10691590Srgrimesexpected) results. 10701590Srgrimes 10711590SrgrimesIf you plan on converting source files which contain such code, it is 1072144467Shartirecommended that you first make sure that each conditionally compiled 1073144467Shartiregion of source code which contains an alternative function header also 1074144467Sharticontains at least one additional follower token (past the final right 10751590Srgrimesparenthesis of the function header). This should circumvent the 1076144467Shartiproblem. 1077144467Sharti 1078144467Sharti@item 1079144467Sharti@command{unprotoize} can become confused when trying to convert a function 1080144467Shartidefinition or declaration which contains a declaration for a 1081144467Shartipointer-to-function formal argument which has the same name as the 1082144467Shartifunction being defined or declared. We recommend you avoid such choices 1083144467Shartiof formal parameter names. 1084144467Sharti 1085144467Sharti@item 1086144467ShartiYou might also want to correct some of the indentation by hand and break 1087144467Shartilong lines. (The conversion programs don't write lines longer than 1088144467Shartieighty characters in any case.) 1089144467Sharti@end itemize 1090144467Sharti 1091144467Sharti@node Non-bugs 1092144467Sharti@section Certain Changes We Don't Want to Make 1093144467Sharti 1094144467ShartiThis section lists changes that people frequently request, but which 1095144467Shartiwe do not make because we think GCC is better without them. 1096144467Sharti 1097144467Sharti@itemize @bullet 1098144467Sharti@item 1099144467ShartiChecking the number and type of arguments to a function which has an 1100144467Shartiold-fashioned definition and no prototype. 1101144467Sharti 11021590SrgrimesSuch a feature would work only occasionally---only for calls that appear 1103143703Shartiin the same file as the called function, following the definition. The 1104144657Shartionly way to check all calls reliably is to add a prototype for the 1105144657Shartifunction. But adding a prototype eliminates the motivation for this 1106144467Shartifeature. So the feature is not worthwhile. 1107144467Sharti 1108144467Sharti@item 1109144467ShartiWarning about using an expression whose type is signed as a shift count. 1110144467Sharti 1111144467ShartiShift count operands are probably signed more often than unsigned. 1112144467ShartiWarning about this would cause far more annoyance than good. 1113144467Sharti 1114146027Sharti@item 1115146027ShartiWarning about assigning a signed value to an unsigned variable. 1116144467Sharti 11171590SrgrimesSuch assignments must be very common; warning about them would cause 1118144467Shartimore annoyance than good. 1119144467Sharti 1120144467Sharti@item 11211590SrgrimesWarning when a non-void function value is ignored. 1122144467Sharti 1123186279SfjoeComing as I do from a Lisp background, I balk at the idea that there is 1124144467Shartisomething dangerous about discarding a value. There are functions that 1125144467Shartireturn values which some callers may find useful; it makes no sense to 1126144467Sharticlutter the program with a cast to @code{void} whenever the value isn't 1127144467Shartiuseful. 1128144467Sharti 11291590Srgrimes@item 1130144467Sharti@opindex fshort-enums 11311590SrgrimesMaking @option{-fshort-enums} the default. 1132186279Sfjoe 1133144467ShartiThis would cause storage layout to be incompatible with most other C 1134144467Sharticompilers. And it doesn't seem very important, given that you can get 1135144467Shartithe same result in other ways. The case where it matters most is when 1136144467Shartithe enumeration-valued object is inside a structure, and in that case 1137144467Shartiyou can specify a field width explicitly. 1138144467Sharti 1139144467Sharti@item 11408874SrgrimesMaking bit-fields unsigned by default on particular machines where ``the 1141144657ShartiABI standard'' says to do so. 1142144467Sharti 1143144467ShartiThe ISO C standard leaves it up to the implementation whether a bit-field 1144144467Shartideclared plain @code{int} is signed or not. This in effect creates two 1145186279Sfjoealternative dialects of C@. 1146144467Sharti 11471590Srgrimes@opindex fsigned-bitfields 11481590Srgrimes@opindex funsigned-bitfields 1149144467ShartiThe GNU C compiler supports both dialects; you can specify the signed 1150144467Shartidialect with @option{-fsigned-bitfields} and the unsigned dialect with 11511590Srgrimes@option{-funsigned-bitfields}. However, this leaves open the question of 1152104696Sjmallettwhich dialect to use by default. 11531590Srgrimes 11541590SrgrimesCurrently, the preferred dialect makes plain bit-fields signed, because 11551590Srgrimesthis is simplest. Since @code{int} is the same as @code{signed int} in 11561590Srgrimesevery other context, it is cleanest for them to be the same in bit-fields 11571590Srgrimesas well. 11581590Srgrimes 1159104696SjmallettSome computer manufacturers have published Application Binary Interface 11601590Srgrimesstandards which specify that plain bit-fields should be unsigned. It is 1161144467Shartia mistake, however, to say anything about this issue in an ABI@. This is 1162144467Shartibecause the handling of plain bit-fields distinguishes two dialects of C@. 11631590SrgrimesBoth dialects are meaningful on every type of machine. Whether a 1164144467Shartiparticular object file was compiled using signed bit-fields or unsigned 1165144467Shartiis of no concern to other object files, even if they access the same 1166144467Shartibit-fields in the same data structures. 1167144467Sharti 1168144467ShartiA given program is written in one or the other of these two dialects. 1169144467ShartiThe program stands a chance to work on most any machine if it is 1170144467Sharticompiled with the proper dialect. It is unlikely to work at all if 11718874Srgrimescompiled with the wrong dialect. 1172144467Sharti 1173144467ShartiMany users appreciate the GNU C compiler because it provides an 1174144467Shartienvironment that is uniform across machines. These users would be 1175144467Shartiinconvenienced if the compiler treated plain bit-fields differently on 11761590Srgrimescertain machines. 1177144467Sharti 1178144467ShartiOccasionally users write programs intended only for a particular machine 1179144467Shartitype. On these occasions, the users would benefit if the GNU C compiler 11801590Srgrimeswere to support by default the same dialect as the other compilers on 1181144467Shartithat machine. But such applications are rare. And users writing a 1182144467Shartiprogram to run on more than one type of machine cannot possibly benefit 1183144467Shartifrom this kind of compatibility. 1184144467Sharti 1185144467ShartiThis is why GCC does and will treat plain bit-fields in the same 1186144467Shartifashion on all types of machines (by default). 11871590Srgrimes 1188144467ShartiThere are some arguments for making bit-fields unsigned by default on all 1189144467Shartimachines. If, for example, this becomes a universal de facto standard, 1190144467Shartiit would make sense for GCC to go along with it. This is something 11911590Srgrimesto be considered in the future. 1192144467Sharti 1193144467Sharti(Of course, users strongly concerned about portability should indicate 11941590Srgrimesexplicitly in each bit-field whether it is signed or not. In this way, 1195144467Shartithey write programs which have the same meaning in both C dialects.) 1196144467Sharti 1197144467Sharti@item 1198144467Sharti@opindex ansi 1199144467Sharti@opindex std 1200144467ShartiUndefining @code{__STDC__} when @option{-ansi} is not used. 1201144467Sharti 1202144467ShartiCurrently, GCC defines @code{__STDC__} unconditionally. This provides 1203144467Shartigood results in practice. 1204144467Sharti 1205144467ShartiProgrammers normally use conditionals on @code{__STDC__} to ask whether 1206144467Shartiit is safe to use certain features of ISO C, such as function 1207144467Shartiprototypes or ISO token concatenation. Since plain @command{gcc} supports 1208144467Shartiall the features of ISO C, the correct answer to these questions is 1209144467Sharti``yes''. 12101590Srgrimes 12111590SrgrimesSome users try to use @code{__STDC__} to check for the availability of 12121590Srgrimescertain library facilities. This is actually incorrect usage in an ISO 12131590SrgrimesC program, because the ISO C standard says that a conforming 1214144467Shartifreestanding implementation should define @code{__STDC__} even though it 1215144467Shartidoes not have the library facilities. @samp{gcc -ansi -pedantic} is a 12168874Srgrimesconforming freestanding implementation, and it is therefore required to 12171590Srgrimesdefine @code{__STDC__}, even though it does not come with an ISO C 12181590Srgrimeslibrary. 12191590Srgrimes 12201590SrgrimesSometimes people say that defining @code{__STDC__} in a compiler that 12211590Srgrimesdoes not completely conform to the ISO C standard somehow violates the 12221590Srgrimesstandard. This is illogical. The standard is a standard for compilers 12231590Srgrimesthat claim to support ISO C, such as @samp{gcc -ansi}---not for other 12241590Srgrimescompilers such as plain @command{gcc}. Whatever the ISO C standard says 12251590Srgrimesis relevant to the design of plain @command{gcc} without @option{-ansi} only 1226104696Sjmallettfor pragmatic reasons, not as a requirement. 12271590Srgrimes 1228138232ShartiGCC normally defines @code{__STDC__} to be 1, and in addition 1229144467Shartidefines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, 1230144467Shartior a @option{-std} option for strict conformance to some version of ISO C@. 1231144467ShartiOn some hosts, system include files use a different convention, where 1232144467Sharti@code{__STDC__} is normally 0, but is 1 if the user specifies strict 1233144467Sharticonformance to the C Standard. GCC follows the host convention when 1234144467Shartiprocessing system include files, but when processing user files it follows 1235144657Shartithe usual GNU C convention. 1236144467Sharti 1237144467Sharti@item 1238144467ShartiUndefining @code{__STDC__} in C++. 1239144467Sharti 1240144467ShartiPrograms written to compile with C++-to-C translators get the 1241144467Shartivalue of @code{__STDC__} that goes with the C compiler that is 1242144467Shartisubsequently used. These programs must test @code{__STDC__} 1243144467Shartito determine what kind of C preprocessor that compiler uses: 1244144467Shartiwhether they should concatenate tokens in the ISO C fashion 1245144467Shartior in the traditional fashion. 1246144467Sharti 1247146580ShartiThese programs work properly with GNU C++ if @code{__STDC__} is defined. 124818730SsteveThey would not work otherwise. 1249144467Sharti 1250144467ShartiIn addition, many header files are written to provide prototypes in ISO 1251144467ShartiC but not in traditional C@. Many of these header files can work without 1252144467Shartichange in C++ provided @code{__STDC__} is defined. If @code{__STDC__} 1253144467Shartiis not defined, they will all fail, and will all need to be changed to 1254144467Shartitest explicitly for C++ as well. 1255144467Sharti 1256144467Sharti@item 1257144467ShartiDeleting ``empty'' loops. 1258144467Sharti 1259144467ShartiHistorically, GCC has not deleted ``empty'' loops under the 1260144467Shartiassumption that the most likely reason you would put one in a program is 1261144467Shartito have a delay, so deleting them will not make real programs run any 1262144467Shartifaster. 1263144467Sharti 1264144467ShartiHowever, the rationale here is that optimization of a nonempty loop 1265144467Sharticannot produce an empty one, which holds for C but is not always the 1266144467Sharticase for C++. 1267144467Sharti 1268144467Sharti@opindex funroll-loops 1269144467ShartiMoreover, with @option{-funroll-loops} small ``empty'' loops are already 1270144467Shartiremoved, so the current behavior is both sub-optimal and inconsistent 1271176808Sobrienand will change in the future. 1272144467Sharti 1273144467Sharti@item 1274144467ShartiMaking side effects happen in the same order as in some other compiler. 1275176808Sobrien 1276144467Sharti@cindex side effects, order of evaluation 1277144467Sharti@cindex order of evaluation, side effects 1278144467ShartiIt is never safe to depend on the order of evaluation of side effects. 1279144467ShartiFor example, a function call like this may very well behave differently 1280144467Shartifrom one compiler to another: 12811590Srgrimes 1282144467Sharti@example 12831590Srgrimesvoid func (int, int); 12841590Srgrimes 1285144467Shartiint i = 2; 1286144467Shartifunc (i++, i++); 12871590Srgrimes@end example 12881590Srgrimes 12891590SrgrimesThere is no guarantee (in either the C or the C++ standard language 12901590Srgrimesdefinitions) that the increments will be evaluated in any particular 12911590Srgrimesorder. Either increment might happen first. @code{func} might get the 12921590Srgrimesarguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. 12931590Srgrimes 12941590Srgrimes@item 1295104696SjmallettNot allowing structures with volatile fields in registers. 12961590Srgrimes 1297146129ShartiStrictly speaking, there is no prohibition in the ISO C standard 12988874Srgrimesagainst allowing structures with volatile fields in registers, but 1299144467Shartiit does not seem to make any sense and is probably not what you wanted 1300146061Shartito do. So the compiler will give an error message in this case. 13018874Srgrimes 1302144467Sharti@item 1303144467ShartiMaking certain warnings into errors by default. 1304144467Sharti 1305144467ShartiSome ISO C testsuites report failure when the compiler does not produce 1306144467Shartian error message for a certain program. 1307144467Sharti 13081590Srgrimes@opindex pedantic-errors 13098874SrgrimesISO C requires a ``diagnostic'' message for certain kinds of invalid 13101590Srgrimesprograms, but a warning is defined by GCC to count as a diagnostic. If 1311144467ShartiGCC produces a warning but not an error, that is correct ISO C support. 1312144467ShartiIf test suites call this ``failure'', they should be run with the GCC 1313144467Shartioption @option{-pedantic-errors}, which will turn these warnings into 1314144467Shartierrors. 13151590Srgrimes 1316144657Sharti@end itemize 1317144467Sharti 1318144467Sharti@node Warnings and Errors 1319144467Sharti@section Warning Messages and Error Messages 13201590Srgrimes 13211590Srgrimes@cindex error messages 1322146129Sharti@cindex warnings vs errors 1323146129Sharti@cindex messages, warning and error 1324146129ShartiThe GNU compiler can produce two kinds of diagnostics: errors and 1325146129Shartiwarnings. Each kind has a different purpose: 1326146129Sharti 1327146129Sharti@itemize @w{} 1328146129Sharti@item 1329146129Sharti@dfn{Errors} report problems that make it impossible to compile your 1330146129Shartiprogram. GCC reports errors with the source file name and line 1331146129Shartinumber where the problem is apparent. 1332146129Sharti 1333146129Sharti@item 1334146129Sharti@dfn{Warnings} report other unusual conditions in your code that 1335146129Sharti@emph{may} indicate a problem, although compilation can (and does) 1336146129Shartiproceed. Warning messages also report the source file name and line 1337146129Shartinumber, but include the text @samp{warning:} to distinguish them 1338146129Shartifrom error messages. 1339146129Sharti@end itemize 1340146129Sharti 1341146129ShartiWarnings may indicate danger points where you should check to make sure 1342146129Shartithat your program really does what you intend; or the use of obsolete 1343146129Shartifeatures; or the use of nonstandard features of GNU C or C++. Many 1344146156Shartiwarnings are issued only if you ask for them, with one of the @option{-W} 1345146129Shartioptions (for instance, @option{-Wall} requests a variety of useful 1346146129Shartiwarnings). 1347146129Sharti 1348146129Sharti@opindex pedantic 1349146129Sharti@opindex pedantic-errors 1350146130ShartiGCC always tries to compile your program if possible; it never 1351144467Shartigratuitously rejects a program whose meaning is clear merely because 1352144467Sharti(for instance) it fails to conform to a standard. In some cases, 1353146130Shartihowever, the C and C++ standards specify that certain extensions are 1354146130Shartiforbidden, and a diagnostic @emph{must} be issued by a conforming 1355144665Sharticompiler. The @option{-pedantic} option tells GCC to issue warnings in 1356144665Shartisuch cases; @option{-pedantic-errors} says to make them errors instead. 1357144665ShartiThis does not mean that @emph{all} non-ISO constructs get warnings 1358144467Shartior errors. 1359144467Sharti 1360144467Sharti@xref{Warning Options,,Options to Request or Suppress Warnings}, for 1361146574Shartimore detail on these and related command-line options. 1362146129Sharti