1@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 2@c 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 3@c Free Software Foundation, Inc. 4@c This is part of the GCC manual. 5@c For copying conditions, see the file gcc.texi. 6 7@node Trouble 8@chapter Known Causes of Trouble with GCC 9@cindex bugs, known 10@cindex installation trouble 11@cindex known causes of trouble 12 13This section describes known problems that affect users of GCC@. Most 14of these are not GCC bugs per se---if they were, we would fix them. 15But the result for a user may be like the result of a bug. 16 17Some of these problems are due to bugs in other software, some are 18missing features that are too much work to add, and some are places 19where people's opinions differ as to what is best. 20 21@menu 22* Actual Bugs:: Bugs we will fix later. 23* Cross-Compiler Problems:: Common problems of cross compiling with GCC. 24* Interoperation:: Problems using GCC with other compilers, 25 and with certain linkers, assemblers and debuggers. 26* Incompatibilities:: GCC is incompatible with traditional C. 27* Fixed Headers:: GCC uses corrected versions of system header files. 28 This is necessary, but doesn't always work smoothly. 29* Standard Libraries:: GCC uses the system C library, which might not be 30 compliant with the ISO C standard. 31* Disappointments:: Regrettable things we can't change, but not quite bugs. 32* C++ Misunderstandings:: Common misunderstandings with GNU C++. 33* Non-bugs:: Things we think are right, but some others disagree. 34* Warnings and Errors:: Which problems in your code get warnings, 35 and which get errors. 36@end menu 37 38@node Actual Bugs 39@section Actual Bugs We Haven't Fixed Yet 40 41@itemize @bullet 42@item 43The @code{fixincludes} script interacts badly with automounters; if the 44directory of system header files is automounted, it tends to be 45unmounted while @code{fixincludes} is running. This would seem to be a 46bug in the automounter. We don't know any good way to work around it. 47@end itemize 48 49@node Cross-Compiler Problems 50@section Cross-Compiler Problems 51 52You may run into problems with cross compilation on certain machines, 53for several reasons. 54 55@itemize @bullet 56@item 57At present, the program @file{mips-tfile} which adds debug 58support to object files on Tru64 UNIX systems does not work in a cross 59compile environment. 60@end itemize 61 62@node Interoperation 63@section Interoperation 64 65This section lists various difficulties encountered in using GCC 66together with other compilers or with the assemblers, linkers, 67libraries and debuggers on certain systems. 68 69@itemize @bullet 70@item 71On many platforms, GCC supports a different ABI for C++ than do other 72compilers, so the object files compiled by GCC cannot be used with object 73files generated by another C++ compiler. 74 75An area where the difference is most apparent is name mangling. The use 76of different name mangling is intentional, to protect you from more subtle 77problems. 78Compilers differ as to many internal details of C++ implementation, 79including: how class instances are laid out, how multiple inheritance is 80implemented, and how virtual function calls are handled. If the name 81encoding were made the same, your programs would link against libraries 82provided from other compilers---but the programs would then crash when 83run. Incompatible libraries are then detected at link time, rather than 84at run time. 85 86@item 87On some BSD systems, including some versions of Ultrix, use of profiling 88causes static variable destructors (currently used only in C++) not to 89be run. 90 91@item 92On some SGI systems, when you use @option{-lgl_s} as an option, 93it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}. 94Naturally, this does not happen when you use GCC@. 95You must specify all three options explicitly. 96 97@item 98On a SPARC, GCC aligns all values of type @code{double} on an 8-byte 99boundary, and it expects every @code{double} to be so aligned. The Sun 100compiler usually gives @code{double} values 8-byte alignment, with one 101exception: function arguments of type @code{double} may not be aligned. 102 103As a result, if a function compiled with Sun CC takes the address of an 104argument of type @code{double} and passes this pointer of type 105@code{double *} to a function compiled with GCC, dereferencing the 106pointer may cause a fatal signal. 107 108One way to solve this problem is to compile your entire program with GCC@. 109Another solution is to modify the function that is compiled with 110Sun CC to copy the argument into a local variable; local variables 111are always properly aligned. A third solution is to modify the function 112that uses the pointer to dereference it via the following function 113@code{access_double} instead of directly with @samp{*}: 114 115@smallexample 116inline double 117access_double (double *unaligned_ptr) 118@{ 119 union d2i @{ double d; int i[2]; @}; 120 121 union d2i *p = (union d2i *) unaligned_ptr; 122 union d2i u; 123 124 u.i[0] = p->i[0]; 125 u.i[1] = p->i[1]; 126 127 return u.d; 128@} 129@end smallexample 130 131@noindent 132Storing into the pointer can be done likewise with the same union. 133 134@item 135On Solaris, the @code{malloc} function in the @file{libmalloc.a} library 136may allocate memory that is only 4 byte aligned. Since GCC on the 137SPARC assumes that doubles are 8 byte aligned, this may result in a 138fatal signal if doubles are stored in memory allocated by the 139@file{libmalloc.a} library. 140 141The solution is to not use the @file{libmalloc.a} library. Use instead 142@code{malloc} and related functions from @file{libc.a}; they do not have 143this problem. 144 145@item 146On the HP PA machine, ADB sometimes fails to work on functions compiled 147with GCC@. Specifically, it fails to work on functions that use 148@code{alloca} or variable-size arrays. This is because GCC doesn't 149generate HP-UX unwind descriptors for such functions. It may even be 150impossible to generate them. 151 152@item 153Debugging (@option{-g}) is not supported on the HP PA machine, unless you use 154the preliminary GNU tools. 155 156@item 157Taking the address of a label may generate errors from the HP-UX 158PA assembler. GAS for the PA does not have this problem. 159 160@item 161Using floating point parameters for indirect calls to static functions 162will not work when using the HP assembler. There simply is no way for GCC 163to specify what registers hold arguments for static functions when using 164the HP assembler. GAS for the PA does not have this problem. 165 166@item 167In extremely rare cases involving some very large functions you may 168receive errors from the HP linker complaining about an out of bounds 169unconditional branch offset. This used to occur more often in previous 170versions of GCC, but is now exceptionally rare. If you should run 171into it, you can work around by making your function smaller. 172 173@item 174GCC compiled code sometimes emits warnings from the HP-UX assembler of 175the form: 176 177@smallexample 178(warning) Use of GR3 when 179 frame >= 8192 may cause conflict. 180@end smallexample 181 182These warnings are harmless and can be safely ignored. 183 184@item 185In extremely rare cases involving some very large functions you may 186receive errors from the AIX Assembler complaining about a displacement 187that is too large. If you should run into it, you can work around by 188making your function smaller. 189 190@item 191The @file{libstdc++.a} library in GCC relies on the SVR4 dynamic 192linker semantics which merges global symbols between libraries and 193applications, especially necessary for C++ streams functionality. 194This is not the default behavior of AIX shared libraries and dynamic 195linking. @file{libstdc++.a} is built on AIX with ``runtime-linking'' 196enabled so that symbol merging can occur. To utilize this feature, 197the application linked with @file{libstdc++.a} must include the 198@option{-Wl,-brtl} flag on the link line. G++ cannot impose this 199because this option may interfere with the semantics of the user 200program and users may not always use @samp{g++} to link his or her 201application. Applications are not required to use the 202@option{-Wl,-brtl} flag on the link line---the rest of the 203@file{libstdc++.a} library which is not dependent on the symbol 204merging semantics will continue to function correctly. 205 206@item 207An application can interpose its own definition of functions for 208functions invoked by @file{libstdc++.a} with ``runtime-linking'' 209enabled on AIX@. To accomplish this the application must be linked 210with ``runtime-linking'' option and the functions explicitly must be 211exported by the application (@option{-Wl,-brtl,-bE:exportfile}). 212 213@item 214AIX on the RS/6000 provides support (NLS) for environments outside of 215the United States. Compilers and assemblers use NLS to support 216locale-specific representations of various objects including 217floating-point numbers (@samp{.} vs @samp{,} for separating decimal 218fractions). There have been problems reported where the library linked 219with GCC does not produce the same floating-point formats that the 220assembler accepts. If you have this problem, set the @env{LANG} 221environment variable to @samp{C} or @samp{En_US}. 222 223@item 224@opindex fdollars-in-identifiers 225Even if you specify @option{-fdollars-in-identifiers}, 226you cannot successfully use @samp{$} in identifiers on the RS/6000 due 227to a restriction in the IBM assembler. GAS supports these 228identifiers. 229 230@end itemize 231 232@node Incompatibilities 233@section Incompatibilities of GCC 234@cindex incompatibilities of GCC 235@opindex traditional 236 237There are several noteworthy incompatibilities between GNU C and K&R 238(non-ISO) versions of C@. 239 240@itemize @bullet 241@cindex string constants 242@cindex read-only strings 243@cindex shared strings 244@item 245GCC normally makes string constants read-only. If several 246identical-looking string constants are used, GCC stores only one 247copy of the string. 248 249@cindex @code{mktemp}, and constant strings 250One consequence is that you cannot call @code{mktemp} with a string 251constant argument. The function @code{mktemp} always alters the 252string its argument points to. 253 254@cindex @code{sscanf}, and constant strings 255@cindex @code{fscanf}, and constant strings 256@cindex @code{scanf}, and constant strings 257Another consequence is that @code{sscanf} does not work on some very 258old systems when passed a string constant as its format control string 259or input. This is because @code{sscanf} incorrectly tries to write 260into the string constant. Likewise @code{fscanf} and @code{scanf}. 261 262The solution to these problems is to change the program to use 263@code{char}-array variables with initialization strings for these 264purposes instead of string constants. 265 266@item 267@code{-2147483648} is positive. 268 269This is because 2147483648 cannot fit in the type @code{int}, so 270(following the ISO C rules) its data type is @code{unsigned long int}. 271Negating this value yields 2147483648 again. 272 273@item 274GCC does not substitute macro arguments when they appear inside of 275string constants. For example, the following macro in GCC 276 277@smallexample 278#define foo(a) "a" 279@end smallexample 280 281@noindent 282will produce output @code{"a"} regardless of what the argument @var{a} is. 283 284@cindex @code{setjmp} incompatibilities 285@cindex @code{longjmp} incompatibilities 286@item 287When you use @code{setjmp} and @code{longjmp}, the only automatic 288variables guaranteed to remain valid are those declared 289@code{volatile}. This is a consequence of automatic register 290allocation. Consider this function: 291 292@smallexample 293jmp_buf j; 294 295foo () 296@{ 297 int a, b; 298 299 a = fun1 (); 300 if (setjmp (j)) 301 return a; 302 303 a = fun2 (); 304 /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ 305 return a + fun3 (); 306@} 307@end smallexample 308 309Here @code{a} may or may not be restored to its first value when the 310@code{longjmp} occurs. If @code{a} is allocated in a register, then 311its first value is restored; otherwise, it keeps the last value stored 312in it. 313 314@opindex W 315If you use the @option{-W} option with the @option{-O} option, you will 316get a warning when GCC thinks such a problem might be possible. 317 318@item 319Programs that use preprocessing directives in the middle of macro 320arguments do not work with GCC@. For example, a program like this 321will not work: 322 323@smallexample 324@group 325foobar ( 326#define luser 327 hack) 328@end group 329@end smallexample 330 331ISO C does not permit such a construct. 332 333@item 334K&R compilers allow comments to cross over an inclusion boundary 335(i.e.@: started in an include file and ended in the including file). 336 337@cindex external declaration scope 338@cindex scope of external declarations 339@cindex declaration scope 340@item 341Declarations of external variables and functions within a block apply 342only to the block containing the declaration. In other words, they 343have the same scope as any other declaration in the same place. 344 345In some other C compilers, an @code{extern} declaration affects all the 346rest of the file even if it happens within a block. 347 348@item 349In traditional C, you can combine @code{long}, etc., with a typedef name, 350as shown here: 351 352@smallexample 353typedef int foo; 354typedef long foo bar; 355@end smallexample 356 357In ISO C, this is not allowed: @code{long} and other type modifiers 358require an explicit @code{int}. 359 360@cindex typedef names as function parameters 361@item 362PCC allows typedef names to be used as function parameters. 363 364@item 365Traditional C allows the following erroneous pair of declarations to 366appear together in a given scope: 367 368@smallexample 369typedef int foo; 370typedef foo foo; 371@end smallexample 372 373@item 374GCC treats all characters of identifiers as significant. According to 375K&R-1 (2.2), ``No more than the first eight characters are significant, 376although more may be used.''. Also according to K&R-1 (2.2), ``An 377identifier is a sequence of letters and digits; the first character must 378be a letter. The underscore _ counts as a letter.'', but GCC also 379allows dollar signs in identifiers. 380 381@cindex whitespace 382@item 383PCC allows whitespace in the middle of compound assignment operators 384such as @samp{+=}. GCC, following the ISO standard, does not 385allow this. 386 387@cindex apostrophes 388@cindex @code{'} 389@item 390GCC complains about unterminated character constants inside of 391preprocessing conditionals that fail. Some programs have English 392comments enclosed in conditionals that are guaranteed to fail; if these 393comments contain apostrophes, GCC will probably report an error. For 394example, this code would produce an error: 395 396@smallexample 397#if 0 398You can't expect this to work. 399#endif 400@end smallexample 401 402The best solution to such a problem is to put the text into an actual 403C comment delimited by @samp{/*@dots{}*/}. 404 405@item 406Many user programs contain the declaration @samp{long time ();}. In the 407past, the system header files on many systems did not actually declare 408@code{time}, so it did not matter what type your program declared it to 409return. But in systems with ISO C headers, @code{time} is declared to 410return @code{time_t}, and if that is not the same as @code{long}, then 411@samp{long time ();} is erroneous. 412 413The solution is to change your program to use appropriate system headers 414(@code{<time.h>} on systems with ISO C headers) and not to declare 415@code{time} if the system header files declare it, or failing that to 416use @code{time_t} as the return type of @code{time}. 417 418@cindex @code{float} as function value type 419@item 420When compiling functions that return @code{float}, PCC converts it to 421a double. GCC actually returns a @code{float}. If you are concerned 422with PCC compatibility, you should declare your functions to return 423@code{double}; you might as well say what you mean. 424 425@cindex structures 426@cindex unions 427@item 428When compiling functions that return structures or unions, GCC 429output code normally uses a method different from that used on most 430versions of Unix. As a result, code compiled with GCC cannot call 431a structure-returning function compiled with PCC, and vice versa. 432 433The method used by GCC is as follows: a structure or union which is 4341, 2, 4 or 8 bytes long is returned like a scalar. A structure or union 435with any other size is stored into an address supplied by the caller 436(usually in a special, fixed register, but on some machines it is passed 437on the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX} 438tells GCC where to pass this address. 439 440By contrast, PCC on most target machines returns structures and unions 441of any size by copying the data into an area of static storage, and then 442returning the address of that storage as if it were a pointer value. 443The caller must copy the data from that memory area to the place where 444the value is wanted. GCC does not use this method because it is 445slower and nonreentrant. 446 447On some newer machines, PCC uses a reentrant convention for all 448structure and union returning. GCC on most of these machines uses a 449compatible convention when returning structures and unions in memory, 450but still returns small structures and unions in registers. 451 452@opindex fpcc-struct-return 453You can tell GCC to use a compatible convention for all structure and 454union returning with the option @option{-fpcc-struct-return}. 455 456@cindex preprocessing tokens 457@cindex preprocessing numbers 458@item 459GCC complains about program fragments such as @samp{0x74ae-0x4000} 460which appear to be two hexadecimal constants separated by the minus 461operator. Actually, this string is a single @dfn{preprocessing token}. 462Each such token must correspond to one token in C@. Since this does not, 463GCC prints an error message. Although it may appear obvious that what 464is meant is an operator and two values, the ISO C standard specifically 465requires that this be treated as erroneous. 466 467A @dfn{preprocessing token} is a @dfn{preprocessing number} if it 468begins with a digit and is followed by letters, underscores, digits, 469periods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, 470@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C90 471mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot 472appear in preprocessing numbers.) 473 474To make the above program fragment valid, place whitespace in front of 475the minus sign. This whitespace will end the preprocessing number. 476@end itemize 477 478@node Fixed Headers 479@section Fixed Header Files 480 481GCC needs to install corrected versions of some system header files. 482This is because most target systems have some header files that won't 483work with GCC unless they are changed. Some have bugs, some are 484incompatible with ISO C, and some depend on special features of other 485compilers. 486 487Installing GCC automatically creates and installs the fixed header 488files, by running a program called @code{fixincludes}. Normally, you 489don't need to pay attention to this. But there are cases where it 490doesn't do the right thing automatically. 491 492@itemize @bullet 493@item 494If you update the system's header files, such as by installing a new 495system version, the fixed header files of GCC are not automatically 496updated. They can be updated using the @command{mkheaders} script 497installed in 498@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. 499 500@item 501On some systems, header file directories contain 502machine-specific symbolic links in certain places. This makes it 503possible to share most of the header files among hosts running the 504same version of the system on different machine models. 505 506The programs that fix the header files do not understand this special 507way of using symbolic links; therefore, the directory of fixed header 508files is good only for the machine model used to build it. 509 510It is possible to make separate sets of fixed header files for the 511different machine models, and arrange a structure of symbolic links so 512as to use the proper set, but you'll have to do this by hand. 513@end itemize 514 515@node Standard Libraries 516@section Standard Libraries 517 518@opindex Wall 519GCC by itself attempts to be a conforming freestanding implementation. 520@xref{Standards,,Language Standards Supported by GCC}, for details of 521what this means. Beyond the library facilities required of such an 522implementation, the rest of the C library is supplied by the vendor of 523the operating system. If that C library doesn't conform to the C 524standards, then your programs might get warnings (especially when using 525@option{-Wall}) that you don't expect. 526 527For example, the @code{sprintf} function on SunOS 4.1.3 returns 528@code{char *} while the C standard says that @code{sprintf} returns an 529@code{int}. The @code{fixincludes} program could make the prototype for 530this function match the Standard, but that would be wrong, since the 531function will still return @code{char *}. 532 533If you need a Standard compliant library, then you need to find one, as 534GCC does not provide one. The GNU C library (called @code{glibc}) 535provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for 536GNU/Linux and HURD-based GNU systems; no recent version of it supports 537other systems, though some very old versions did. Version 2.2 of the 538GNU C library includes nearly complete C99 support. You could also ask 539your operating system vendor if newer libraries are available. 540 541@node Disappointments 542@section Disappointments and Misunderstandings 543 544These problems are perhaps regrettable, but we don't know any practical 545way around them. 546 547@itemize @bullet 548@item 549Certain local variables aren't recognized by debuggers when you compile 550with optimization. 551 552This occurs because sometimes GCC optimizes the variable out of 553existence. There is no way to tell the debugger how to compute the 554value such a variable ``would have had'', and it is not clear that would 555be desirable anyway. So GCC simply does not mention the eliminated 556variable when it writes debugging information. 557 558You have to expect a certain amount of disagreement between the 559executable and your source code, when you use optimization. 560 561@cindex conflicting types 562@cindex scope of declaration 563@item 564Users often think it is a bug when GCC reports an error for code 565like this: 566 567@smallexample 568int foo (struct mumble *); 569 570struct mumble @{ @dots{} @}; 571 572int foo (struct mumble *x) 573@{ @dots{} @} 574@end smallexample 575 576This code really is erroneous, because the scope of @code{struct 577mumble} in the prototype is limited to the argument list containing it. 578It does not refer to the @code{struct mumble} defined with file scope 579immediately below---they are two unrelated types with similar names in 580different scopes. 581 582But in the definition of @code{foo}, the file-scope type is used 583because that is available to be inherited. Thus, the definition and 584the prototype do not match, and you get an error. 585 586This behavior may seem silly, but it's what the ISO standard specifies. 587It is easy enough for you to make your code work by moving the 588definition of @code{struct mumble} above the prototype. It's not worth 589being incompatible with ISO C just to avoid an error for the example 590shown above. 591 592@item 593Accesses to bit-fields even in volatile objects works by accessing larger 594objects, such as a byte or a word. You cannot rely on what size of 595object is accessed in order to read or write the bit-field; it may even 596vary for a given bit-field according to the precise usage. 597 598If you care about controlling the amount of memory that is accessed, use 599volatile but do not use bit-fields. 600 601@item 602GCC comes with shell scripts to fix certain known problems in system 603header files. They install corrected copies of various header files in 604a special directory where only GCC will normally look for them. The 605scripts adapt to various systems by searching all the system header 606files for the problem cases that we know about. 607 608If new system header files are installed, nothing automatically arranges 609to update the corrected header files. They can be updated using the 610@command{mkheaders} script installed in 611@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. 612 613@item 614@cindex floating point precision 615On 68000 and x86 systems, for instance, you can get paradoxical results 616if you test the precise values of floating point numbers. For example, 617you can find that a floating point value which is not a NaN is not equal 618to itself. This results from the fact that the floating point registers 619hold a few more bits of precision than fit in a @code{double} in memory. 620Compiled code moves values between memory and floating point registers 621at its convenience, and moving them into memory truncates them. 622 623@opindex ffloat-store 624You can partially avoid this problem by using the @option{-ffloat-store} 625option (@pxref{Optimize Options}). 626 627@item 628On AIX and other platforms without weak symbol support, templates 629need to be instantiated explicitly and symbols for static members 630of templates will not be generated. 631 632@item 633On AIX, GCC scans object files and library archives for static 634constructors and destructors when linking an application before the 635linker prunes unreferenced symbols. This is necessary to prevent the 636AIX linker from mistakenly assuming that static constructor or 637destructor are unused and removing them before the scanning can occur. 638All static constructors and destructors found will be referenced even 639though the modules in which they occur may not be used by the program. 640This may lead to both increased executable size and unexpected symbol 641references. 642@end itemize 643 644@node C++ Misunderstandings 645@section Common Misunderstandings with GNU C++ 646 647@cindex misunderstandings in C++ 648@cindex surprises in C++ 649@cindex C++ misunderstandings 650C++ is a complex language and an evolving one, and its standard 651definition (the ISO C++ standard) was only recently completed. As a 652result, your C++ compiler may occasionally surprise you, even when its 653behavior is correct. This section discusses some areas that frequently 654give rise to questions of this sort. 655 656@menu 657* Static Definitions:: Static member declarations are not definitions 658* Name lookup:: Name lookup, templates, and accessing members of base classes 659* Temporaries:: Temporaries may vanish before you expect 660* Copy Assignment:: Copy Assignment operators copy virtual bases twice 661@end menu 662 663@node Static Definitions 664@subsection Declare @emph{and} Define Static Members 665 666@cindex C++ static data, declaring and defining 667@cindex static data in C++, declaring and defining 668@cindex declaring static data in C++ 669@cindex defining static data in C++ 670When a class has static data members, it is not enough to @emph{declare} 671the static member; you must also @emph{define} it. For example: 672 673@smallexample 674class Foo 675@{ 676 @dots{} 677 void method(); 678 static int bar; 679@}; 680@end smallexample 681 682This declaration only establishes that the class @code{Foo} has an 683@code{int} named @code{Foo::bar}, and a member function named 684@code{Foo::method}. But you still need to define @emph{both} 685@code{method} and @code{bar} elsewhere. According to the ISO 686standard, you must supply an initializer in one (and only one) source 687file, such as: 688 689@smallexample 690int Foo::bar = 0; 691@end smallexample 692 693Other C++ compilers may not correctly implement the standard behavior. 694As a result, when you switch to @command{g++} from one of these compilers, 695you may discover that a program that appeared to work correctly in fact 696does not conform to the standard: @command{g++} reports as undefined 697symbols any static data members that lack definitions. 698 699 700@node Name lookup 701@subsection Name lookup, templates, and accessing members of base classes 702 703@cindex base class members 704@cindex two-stage name lookup 705@cindex dependent name lookup 706 707The C++ standard prescribes that all names that are not dependent on 708template parameters are bound to their present definitions when parsing 709a template function or class.@footnote{The C++ standard just uses the 710term ``dependent'' for names that depend on the type or value of 711template parameters. This shorter term will also be used in the rest of 712this section.} Only names that are dependent are looked up at the point 713of instantiation. For example, consider 714 715@smallexample 716 void foo(double); 717 718 struct A @{ 719 template <typename T> 720 void f () @{ 721 foo (1); // @r{1} 722 int i = N; // @r{2} 723 T t; 724 t.bar(); // @r{3} 725 foo (t); // @r{4} 726 @} 727 728 static const int N; 729 @}; 730@end smallexample 731 732Here, the names @code{foo} and @code{N} appear in a context that does 733not depend on the type of @code{T}. The compiler will thus require that 734they are defined in the context of use in the template, not only before 735the point of instantiation, and will here use @code{::foo(double)} and 736@code{A::N}, respectively. In particular, it will convert the integer 737value to a @code{double} when passing it to @code{::foo(double)}. 738 739Conversely, @code{bar} and the call to @code{foo} in the fourth marked 740line are used in contexts that do depend on the type of @code{T}, so 741they are only looked up at the point of instantiation, and you can 742provide declarations for them after declaring the template, but before 743instantiating it. In particular, if you instantiate @code{A::f<int>}, 744the last line will call an overloaded @code{::foo(int)} if one was 745provided, even if after the declaration of @code{struct A}. 746 747This distinction between lookup of dependent and non-dependent names is 748called two-stage (or dependent) name lookup. G++ implements it 749since version 3.4. 750 751Two-stage name lookup sometimes leads to situations with behavior 752different from non-template codes. The most common is probably this: 753 754@smallexample 755 template <typename T> struct Base @{ 756 int i; 757 @}; 758 759 template <typename T> struct Derived : public Base<T> @{ 760 int get_i() @{ return i; @} 761 @}; 762@end smallexample 763 764In @code{get_i()}, @code{i} is not used in a dependent context, so the 765compiler will look for a name declared at the enclosing namespace scope 766(which is the global scope here). It will not look into the base class, 767since that is dependent and you may declare specializations of 768@code{Base} even after declaring @code{Derived}, so the compiler can't 769really know what @code{i} would refer to. If there is no global 770variable @code{i}, then you will get an error message. 771 772In order to make it clear that you want the member of the base class, 773you need to defer lookup until instantiation time, at which the base 774class is known. For this, you need to access @code{i} in a dependent 775context, by either using @code{this->i} (remember that @code{this} is of 776type @code{Derived<T>*}, so is obviously dependent), or using 777@code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought 778into scope by a @code{using}-declaration. 779 780Another, similar example involves calling member functions of a base 781class: 782 783@smallexample 784 template <typename T> struct Base @{ 785 int f(); 786 @}; 787 788 template <typename T> struct Derived : Base<T> @{ 789 int g() @{ return f(); @}; 790 @}; 791@end smallexample 792 793Again, the call to @code{f()} is not dependent on template arguments 794(there are no arguments that depend on the type @code{T}, and it is also 795not otherwise specified that the call should be in a dependent context). 796Thus a global declaration of such a function must be available, since 797the one in the base class is not visible until instantiation time. The 798compiler will consequently produce the following error message: 799 800@smallexample 801 x.cc: In member function `int Derived<T>::g()': 802 x.cc:6: error: there are no arguments to `f' that depend on a template 803 parameter, so a declaration of `f' must be available 804 x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but 805 allowing the use of an undeclared name is deprecated) 806@end smallexample 807 808To make the code valid either use @code{this->f()}, or 809@code{Base<T>::f()}. Using the @option{-fpermissive} flag will also let 810the compiler accept the code, by marking all function calls for which no 811declaration is visible at the time of definition of the template for 812later lookup at instantiation time, as if it were a dependent call. 813We do not recommend using @option{-fpermissive} to work around invalid 814code, and it will also only catch cases where functions in base classes 815are called, not where variables in base classes are used (as in the 816example above). 817 818Note that some compilers (including G++ versions prior to 3.4) get these 819examples wrong and accept above code without an error. Those compilers 820do not implement two-stage name lookup correctly. 821 822 823@node Temporaries 824@subsection Temporaries May Vanish Before You Expect 825 826@cindex temporaries, lifetime of 827@cindex portions of temporary objects, pointers to 828It is dangerous to use pointers or references to @emph{portions} of a 829temporary object. The compiler may very well delete the object before 830you expect it to, leaving a pointer to garbage. The most common place 831where this problem crops up is in classes like string classes, 832especially ones that define a conversion function to type @code{char *} 833or @code{const char *}---which is one reason why the standard 834@code{string} class requires you to call the @code{c_str} member 835function. However, any class that returns a pointer to some internal 836structure is potentially subject to this problem. 837 838For example, a program may use a function @code{strfunc} that returns 839@code{string} objects, and another function @code{charfunc} that 840operates on pointers to @code{char}: 841 842@smallexample 843string strfunc (); 844void charfunc (const char *); 845 846void 847f () 848@{ 849 const char *p = strfunc().c_str(); 850 @dots{} 851 charfunc (p); 852 @dots{} 853 charfunc (p); 854@} 855@end smallexample 856 857@noindent 858In this situation, it may seem reasonable to save a pointer to the C 859string returned by the @code{c_str} member function and use that rather 860than call @code{c_str} repeatedly. However, the temporary string 861created by the call to @code{strfunc} is destroyed after @code{p} is 862initialized, at which point @code{p} is left pointing to freed memory. 863 864Code like this may run successfully under some other compilers, 865particularly obsolete cfront-based compilers that delete temporaries 866along with normal local variables. However, the GNU C++ behavior is 867standard-conforming, so if your program depends on late destruction of 868temporaries it is not portable. 869 870The safe way to write such code is to give the temporary a name, which 871forces it to remain until the end of the scope of the name. For 872example: 873 874@smallexample 875const string& tmp = strfunc (); 876charfunc (tmp.c_str ()); 877@end smallexample 878 879@node Copy Assignment 880@subsection Implicit Copy-Assignment for Virtual Bases 881 882When a base class is virtual, only one subobject of the base class 883belongs to each full object. Also, the constructors and destructors are 884invoked only once, and called from the most-derived class. However, such 885objects behave unspecified when being assigned. For example: 886 887@smallexample 888struct Base@{ 889 char *name; 890 Base(char *n) : name(strdup(n))@{@} 891 Base& operator= (const Base& other)@{ 892 free (name); 893 name = strdup (other.name); 894 @} 895@}; 896 897struct A:virtual Base@{ 898 int val; 899 A():Base("A")@{@} 900@}; 901 902struct B:virtual Base@{ 903 int bval; 904 B():Base("B")@{@} 905@}; 906 907struct Derived:public A, public B@{ 908 Derived():Base("Derived")@{@} 909@}; 910 911void func(Derived &d1, Derived &d2) 912@{ 913 d1 = d2; 914@} 915@end smallexample 916 917The C++ standard specifies that @samp{Base::Base} is only called once 918when constructing or copy-constructing a Derived object. It is 919unspecified whether @samp{Base::operator=} is called more than once when 920the implicit copy-assignment for Derived objects is invoked (as it is 921inside @samp{func} in the example). 922 923G++ implements the ``intuitive'' algorithm for copy-assignment: assign all 924direct bases, then assign all members. In that algorithm, the virtual 925base subobject can be encountered more than once. In the example, copying 926proceeds in the following order: @samp{val}, @samp{name} (via 927@code{strdup}), @samp{bval}, and @samp{name} again. 928 929If application code relies on copy-assignment, a user-defined 930copy-assignment operator removes any uncertainties. With such an 931operator, the application can define whether and how the virtual base 932subobject is assigned. 933 934@node Non-bugs 935@section Certain Changes We Don't Want to Make 936 937This section lists changes that people frequently request, but which 938we do not make because we think GCC is better without them. 939 940@itemize @bullet 941@item 942Checking the number and type of arguments to a function which has an 943old-fashioned definition and no prototype. 944 945Such a feature would work only occasionally---only for calls that appear 946in the same file as the called function, following the definition. The 947only way to check all calls reliably is to add a prototype for the 948function. But adding a prototype eliminates the motivation for this 949feature. So the feature is not worthwhile. 950 951@item 952Warning about using an expression whose type is signed as a shift count. 953 954Shift count operands are probably signed more often than unsigned. 955Warning about this would cause far more annoyance than good. 956 957@item 958Warning about assigning a signed value to an unsigned variable. 959 960Such assignments must be very common; warning about them would cause 961more annoyance than good. 962 963@item 964Warning when a non-void function value is ignored. 965 966C contains many standard functions that return a value that most 967programs choose to ignore. One obvious example is @code{printf}. 968Warning about this practice only leads the defensive programmer to 969clutter programs with dozens of casts to @code{void}. Such casts are 970required so frequently that they become visual noise. Writing those 971casts becomes so automatic that they no longer convey useful 972information about the intentions of the programmer. For functions 973where the return value should never be ignored, use the 974@code{warn_unused_result} function attribute (@pxref{Function 975Attributes}). 976 977@item 978@opindex fshort-enums 979Making @option{-fshort-enums} the default. 980 981This would cause storage layout to be incompatible with most other C 982compilers. And it doesn't seem very important, given that you can get 983the same result in other ways. The case where it matters most is when 984the enumeration-valued object is inside a structure, and in that case 985you can specify a field width explicitly. 986 987@item 988Making bit-fields unsigned by default on particular machines where ``the 989ABI standard'' says to do so. 990 991The ISO C standard leaves it up to the implementation whether a bit-field 992declared plain @code{int} is signed or not. This in effect creates two 993alternative dialects of C@. 994 995@opindex fsigned-bitfields 996@opindex funsigned-bitfields 997The GNU C compiler supports both dialects; you can specify the signed 998dialect with @option{-fsigned-bitfields} and the unsigned dialect with 999@option{-funsigned-bitfields}. However, this leaves open the question of 1000which dialect to use by default. 1001 1002Currently, the preferred dialect makes plain bit-fields signed, because 1003this is simplest. Since @code{int} is the same as @code{signed int} in 1004every other context, it is cleanest for them to be the same in bit-fields 1005as well. 1006 1007Some computer manufacturers have published Application Binary Interface 1008standards which specify that plain bit-fields should be unsigned. It is 1009a mistake, however, to say anything about this issue in an ABI@. This is 1010because the handling of plain bit-fields distinguishes two dialects of C@. 1011Both dialects are meaningful on every type of machine. Whether a 1012particular object file was compiled using signed bit-fields or unsigned 1013is of no concern to other object files, even if they access the same 1014bit-fields in the same data structures. 1015 1016A given program is written in one or the other of these two dialects. 1017The program stands a chance to work on most any machine if it is 1018compiled with the proper dialect. It is unlikely to work at all if 1019compiled with the wrong dialect. 1020 1021Many users appreciate the GNU C compiler because it provides an 1022environment that is uniform across machines. These users would be 1023inconvenienced if the compiler treated plain bit-fields differently on 1024certain machines. 1025 1026Occasionally users write programs intended only for a particular machine 1027type. On these occasions, the users would benefit if the GNU C compiler 1028were to support by default the same dialect as the other compilers on 1029that machine. But such applications are rare. And users writing a 1030program to run on more than one type of machine cannot possibly benefit 1031from this kind of compatibility. 1032 1033This is why GCC does and will treat plain bit-fields in the same 1034fashion on all types of machines (by default). 1035 1036There are some arguments for making bit-fields unsigned by default on all 1037machines. If, for example, this becomes a universal de facto standard, 1038it would make sense for GCC to go along with it. This is something 1039to be considered in the future. 1040 1041(Of course, users strongly concerned about portability should indicate 1042explicitly in each bit-field whether it is signed or not. In this way, 1043they write programs which have the same meaning in both C dialects.) 1044 1045@item 1046@opindex ansi 1047@opindex std 1048Undefining @code{__STDC__} when @option{-ansi} is not used. 1049 1050Currently, GCC defines @code{__STDC__} unconditionally. This provides 1051good results in practice. 1052 1053Programmers normally use conditionals on @code{__STDC__} to ask whether 1054it is safe to use certain features of ISO C, such as function 1055prototypes or ISO token concatenation. Since plain @command{gcc} supports 1056all the features of ISO C, the correct answer to these questions is 1057``yes''. 1058 1059Some users try to use @code{__STDC__} to check for the availability of 1060certain library facilities. This is actually incorrect usage in an ISO 1061C program, because the ISO C standard says that a conforming 1062freestanding implementation should define @code{__STDC__} even though it 1063does not have the library facilities. @samp{gcc -ansi -pedantic} is a 1064conforming freestanding implementation, and it is therefore required to 1065define @code{__STDC__}, even though it does not come with an ISO C 1066library. 1067 1068Sometimes people say that defining @code{__STDC__} in a compiler that 1069does not completely conform to the ISO C standard somehow violates the 1070standard. This is illogical. The standard is a standard for compilers 1071that claim to support ISO C, such as @samp{gcc -ansi}---not for other 1072compilers such as plain @command{gcc}. Whatever the ISO C standard says 1073is relevant to the design of plain @command{gcc} without @option{-ansi} only 1074for pragmatic reasons, not as a requirement. 1075 1076GCC normally defines @code{__STDC__} to be 1, and in addition 1077defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, 1078or a @option{-std} option for strict conformance to some version of ISO C@. 1079On some hosts, system include files use a different convention, where 1080@code{__STDC__} is normally 0, but is 1 if the user specifies strict 1081conformance to the C Standard. GCC follows the host convention when 1082processing system include files, but when processing user files it follows 1083the usual GNU C convention. 1084 1085@item 1086Undefining @code{__STDC__} in C++. 1087 1088Programs written to compile with C++-to-C translators get the 1089value of @code{__STDC__} that goes with the C compiler that is 1090subsequently used. These programs must test @code{__STDC__} 1091to determine what kind of C preprocessor that compiler uses: 1092whether they should concatenate tokens in the ISO C fashion 1093or in the traditional fashion. 1094 1095These programs work properly with GNU C++ if @code{__STDC__} is defined. 1096They would not work otherwise. 1097 1098In addition, many header files are written to provide prototypes in ISO 1099C but not in traditional C@. Many of these header files can work without 1100change in C++ provided @code{__STDC__} is defined. If @code{__STDC__} 1101is not defined, they will all fail, and will all need to be changed to 1102test explicitly for C++ as well. 1103 1104@item 1105Deleting ``empty'' loops. 1106 1107Historically, GCC has not deleted ``empty'' loops under the 1108assumption that the most likely reason you would put one in a program is 1109to have a delay, so deleting them will not make real programs run any 1110faster. 1111 1112However, the rationale here is that optimization of a nonempty loop 1113cannot produce an empty one. This held for carefully written C compiled 1114with less powerful optimizers but is not always the case for carefully 1115written C++ or with more powerful optimizers. 1116Thus GCC will remove operations from loops whenever it can determine 1117those operations are not externally visible (apart from the time taken 1118to execute them, of course). In case the loop can be proved to be finite, 1119GCC will also remove the loop itself. 1120 1121Be aware of this when performing timing tests, for instance the 1122following loop can be completely removed, provided 1123@code{some_expression} can provably not change any global state. 1124 1125@smallexample 1126@{ 1127 int sum = 0; 1128 int ix; 1129 1130 for (ix = 0; ix != 10000; ix++) 1131 sum += some_expression; 1132@} 1133@end smallexample 1134 1135Even though @code{sum} is accumulated in the loop, no use is made of 1136that summation, so the accumulation can be removed. 1137 1138@item 1139Making side effects happen in the same order as in some other compiler. 1140 1141@cindex side effects, order of evaluation 1142@cindex order of evaluation, side effects 1143It is never safe to depend on the order of evaluation of side effects. 1144For example, a function call like this may very well behave differently 1145from one compiler to another: 1146 1147@smallexample 1148void func (int, int); 1149 1150int i = 2; 1151func (i++, i++); 1152@end smallexample 1153 1154There is no guarantee (in either the C or the C++ standard language 1155definitions) that the increments will be evaluated in any particular 1156order. Either increment might happen first. @code{func} might get the 1157arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. 1158 1159@item 1160Making certain warnings into errors by default. 1161 1162Some ISO C testsuites report failure when the compiler does not produce 1163an error message for a certain program. 1164 1165@opindex pedantic-errors 1166ISO C requires a ``diagnostic'' message for certain kinds of invalid 1167programs, but a warning is defined by GCC to count as a diagnostic. If 1168GCC produces a warning but not an error, that is correct ISO C support. 1169If testsuites call this ``failure'', they should be run with the GCC 1170option @option{-pedantic-errors}, which will turn these warnings into 1171errors. 1172 1173@end itemize 1174 1175@node Warnings and Errors 1176@section Warning Messages and Error Messages 1177 1178@cindex error messages 1179@cindex warnings vs errors 1180@cindex messages, warning and error 1181The GNU compiler can produce two kinds of diagnostics: errors and 1182warnings. Each kind has a different purpose: 1183 1184@itemize @w{} 1185@item 1186@dfn{Errors} report problems that make it impossible to compile your 1187program. GCC reports errors with the source file name and line 1188number where the problem is apparent. 1189 1190@item 1191@dfn{Warnings} report other unusual conditions in your code that 1192@emph{may} indicate a problem, although compilation can (and does) 1193proceed. Warning messages also report the source file name and line 1194number, but include the text @samp{warning:} to distinguish them 1195from error messages. 1196@end itemize 1197 1198Warnings may indicate danger points where you should check to make sure 1199that your program really does what you intend; or the use of obsolete 1200features; or the use of nonstandard features of GNU C or C++. Many 1201warnings are issued only if you ask for them, with one of the @option{-W} 1202options (for instance, @option{-Wall} requests a variety of useful 1203warnings). 1204 1205@opindex pedantic 1206@opindex pedantic-errors 1207GCC always tries to compile your program if possible; it never 1208gratuitously rejects a program whose meaning is clear merely because 1209(for instance) it fails to conform to a standard. In some cases, 1210however, the C and C++ standards specify that certain extensions are 1211forbidden, and a diagnostic @emph{must} be issued by a conforming 1212compiler. The @option{-pedantic} option tells GCC to issue warnings in 1213such cases; @option{-pedantic-errors} says to make them errors instead. 1214This does not mean that @emph{all} non-ISO constructs get warnings 1215or errors. 1216 1217@xref{Warning Options,,Options to Request or Suppress Warnings}, for 1218more detail on these and related command-line options. 1219