Performance

GCC 4.0 offers better compile times, especially for C++ code. Compile times for C++ programs have improved by as much as 30%. Compile times for C and Objective-C programs have improved by as much as 5%.

Code Optimization

For optimizing code, GCC 4.0 now uses a model called static single assignment or SSA. SSA makes your program faster and more efficient by permitting better and more optimizations. The SSA optimizer does a much better job of finding places where functions can be inlined. In future revisions of GCC, it will be possible to have even better optimizations as developers extend the SSA optimizations.

Better Warnings

Warnings often identify potential bugs in your code. GCC 4.0 performs many more checks (regardless of whether optimizations are enabled and disabled) and reports more warnings because of these checks. Identifying potential problems can help you fix your code in a way that improves overall stability. For example, GCC 4.0 will now warn about potentially ambiguous implicit casts, which could lead to manipulations on an unknown or unexpected object.

GCC 4.0 also promotes some warnings to full-fledged errors. For example, GCC 4.0 now reports an error if you try to use a return value from an Objective-C method whose return type is void, as shown in the following example:

#import <Foundation/Foundation.h>

@interface Foo : NSObject

{

    int _i;

};

- (void) i;

@end

@implementation Foo

- (void) i

{

    return _i;

}

@end

int main(int argc, char **argv)

{

    Foo *f=[[Foo alloc] init];

    int value = [f i];  // this is a hard error in GCC 4.0.

}

Another place where GCC 4.0 now reports an error is when you have a statement in C++ where one array value is assigned to another array value, as shown below:

#include <string.h>

main(int argc, char **argv)

{

    int ARRAY_SIZE = 5;

    int a[ARRAY_SIZE], b[ARRAY_SIZE];

    b[0] = 1;

    a = b; // ERROR with GCC 4.0; Warning with GCC 3.3.

    memcpy(a,b,sizeof(a)); // This is the correct way to copy an array in GCC 4.0.

}

When the preceding code is compiled, GCC reports an error similar to the following:

/tmp/foo.C:9: error: incompatible types in assignment

Better C++ Conformance

GCC 4.0 now provides closer conformance to the C and C++ language standards, which are supported by most major compiler vendors. Better language conformance means your code is now more correct. It also means that it is more portable to other platforms. If your code deviates from the standards, the compiler issues warnings to let you know. If you are developing your code for use on multiple platforms, this feature alone should justify the upgrade.

Compiler Stability

GCC 4.0 contains numerous bug fixes. If you are a C++ developer using GCC 3.3, you are likely to notice many new fixes in GCC 4.0, thanks in part to improved C++ support and a new C++ parser. If you have ever encountered crashes while parsing complex C++ code, you should definitely upgrade to GCC 4.0.

Compiler Support

GCC 4.0 is now the default compiler for Mac OS X v10.4. This means that current development efforts are focused on making GCC 4.0 a better compiler. Even if you do not need the new features or performance offered by the compiler, upgrading means that you will be using the most up-to-date compiler that incorporates all of the latest bug fixes.

Of course, it is important to note that Apple still supports GCC 3.3 and ships the GCC 3.3 compiler alongside GCC 4.0. However, work on the GCC 3.3 code base will be limited to critical bug fixes.

Modifying Xcode Targets

If you are building your project with Xcode, switching to GCC 4.0 involves modifying the settings for each target in your project. How you modify the settings depends on the type of your target.

In some cases, you may want to see which compiler is being used to compile your code and verify the options that are being passed to it. To get this information in Xcode, open the Build Results dialog and show the “build log” pane. (This section is located between the list of errors and the source code pane and is not always visible.) You can also use this pane to view linker error and warning messages. For more information on using this build log, see Xcode 2.0 User Guide.

Modifying Makefiles

If your project is built using Makefiles or custom build scripts, look for references to /usr/bin/gcc-3.3 and change them to /usr/bin/gcc or /usr/bin/gcc-4.0. By default, invoking /usr/bin/gcc launches the default system compiler, which in Mac OS X v10.4 is GCC 4.0.

Changing Compiler and Linker Flags

Some projects may use flags that are supported in GCC 3.3 but were removed in GCC 4.0. You can locate these changes by explicitly checking your compiler options in each Xcode project, or you can simply build your project and wait for error messages regarding illegal options. Once you identify the incorrect flag, go to the settings for the offending target and remove the option. Table 2 lists some other compiler flags that you should think about changing.

Check Your Preprocessor Usage

Do a quick check for bad preprocessor usage. If you have conditional code based on which compiler you're using (as in GCC vs. CodeWarrior), don't forget to update any conditional code looking at the __GNUC__ variable for the compiler version, as shown in the following code listing:

if (__GNUC__ == 3) // old

if (__GNUC__ == 3) || (__GNUC__ == 4) // new

Searching for __GNUC__ in your project should locate all of the relevant code.

If you are migrating a project from CodeWarrior, do not wrap any Mac OS X-specific code using the __MWERKS__ macro. Instead, use the following:

• Use #ifdef __GNUC__ to wrap any GCC-specific code.

• Use #ifdef __APPLE_CC__ to wrap any Mac OS X-specific code.

Use Framework Include Files

If you are migrating a Carbon application from CodeWarrior to Mac OS X, you should remove any references to universal header files and replace them with the appropriate framework header files for Carbon. Framework includes are the standard way to include system header files. For example, to include the header files for the Carbon framework, you would use the following #include statement:

#include <Carbon/Carbon.h>

If you encounter a large number of errors when including the Carbon framework in this manner, you can use the flat Carbon header files instead. The intent of the flat Carbon headers is to help ease the conversion away from universal headers. To include the flat Carbon headers, add /Developer/Headers/FlatCarbon/ to the include path of your project.

Changes for C++ Templates

The most common problem C++ programmers are likely to encounter revolve around changes to support C++ standards compliance. GCC 3.4 (which was shipped by the FSF but not by Apple) started to warn developers about incorrect C++ usage patterns. In GCC 4.0, those warnings are now errors.

One of the more common errors you’re likely to encounter is name lookup problems of the form “x isn’t defined in this scope.” You can find out more about this problem by searching for “name lookup” in the GCC 4.0 documentation. Four of the most common name lookup errors are as follows:

Listing 1 shows an example of an unqualified name belonging to an inherited template class.

Listing 1  Unqualified names in an inherited template

template <typename T> struct Base

{

    int local_var;

    void f();

};

template <typename T> struct Derived : public Base<T>

{

    void g()

    {

        local_var++;    // ERROR: Name not found.

        f();          // ERROR: Name not found.

        this->local_var++;    // OK

        this->f();    // OK

        Derived::f(); // OK

        Base<T>::f(); // OK

    }

};

Changes to lvalue Assignments

The GCC compiler was previously extended to permit non-trivial expressions on the left hand side of an assignment (the lvalue of the assignment). This feature was removed from GCC 4.0 to better match the C and C++ standards and because it was not always clear what the programmer intended in those situations.

Currently, Apple's version of GCC 4.0 compiler only warns about some cases that the FSF's GCC 4.0 compiler would consider an error. Those cases that remain will be eliminated in a future version of Apple’s compiler. What follows are some examples of code that may now generate errors or warnings.

In the following case, GCC 4.0 no longer permits the following conditional lvalue assignments.

(condition ?  lvalue1 : lvalue2) = expr; // Warning: target of assignment not really an lvalue (will be a hard error in future)

To avoid this problem, rewrite the expression so that the left-hand side contains only a variable.

Another case that generates an error involves taking the address of an lvalue variable, as shown here.

&foo = 1; //  ERROR: invalid lvalue in assignment

Instead of this expression, create a temporary variable for the address of foo, and assign a value to that.

In the last case, the problem is caused by dereferencing first and then casting to the target type. Instead, cast the pointer to an appropriate pointer type and then dereference the value.

(u_int32_t)*(vcp->vc_outtok) = sp->sv_caps; // Warning: target of assignment not really an lvalue (hard error in future)

*(u_int32_t*)(vcp->vc_outtok) = sp->sv_caps; // OK

Searching for Framework Headers

Several issues in framework and header searching changed between GCC 3.3 and GCC 4.0.

In GCC 3.3, the compiler would incorrectly search all framework paths when searching for a header in a framework. This is incorrect behavior because there are cases where headers could be retrieved from different installed versions of the framework. For example, some headers might be retrieved from a copy of the framework you are working on while others are retrieved from an officially installed version of the framework.

GCC 4.0 now uses a “first match wins” model for frameworks. With this model, the first time you include a framework header, the compiler makes a note of the location of that framework. Subsequent attempts to retrieve headers from the same framework automatically go to the same location.

In GCC 3.3, the -I and -F flags were treated interchangeably. This is incorrect behavior. In GCC 4.0, you must use the -F flag to get the proper search semantics for your framework directory.

gcc -I/System/Library/MyFrameworks foo.m // worked in gcc-3.3, doesn't work in gcc-4.0.

gcc -F/System/Library/MyFrameworks foo.m // OK

Conflicting Declarations

The following sections list some of the conflicting declarations you may encounter:

// foo.h:

extern int _defaultWidth;  // used by lots of compilation units

// foo.c:

static int _defaultWidth; // local copy -- ERROR: static declaration of '_defaultWidth' follows non-static declaration

int foo(int i) {

  static int bar(int j);  // ERROR: invalid storage class for function 'bar

  bar(i+5);

}

static int bar(int j);  // OK

int foo(int i) {

  bar(i+5);

}

map = new (IOMemoryMap*)[WindowCount]; // ERROR: array bound forbidden after parenthesized type-id

// note: try removing the parentheses around the type-id

map = new IOMemoryMap *[WindowCount];  // OK

class A

{

    int i;

    int foo(int i, int j = 99);

};

int A::foo(int i, int j = 99) // ERROR: default argument given for parameter 1 of 'int A::foo(int)'

    // ERROR: after previous specification in 'int A::foo(int)'

{

 ...

}

int A::foo(int i=10, int j) {  // OK, but visible only in this compilation unit

 ...

}

int A::foo(int i, int j) {  // OK

 ...

}

namespace mynames

{

    void mynames::func();    // ERROR! Explicit qualification in declaration

    void func();            // OK.

};

Kernel Extensions

GCC 4.0 can compile kernel extensions (kexts) that should work with current and previous versions of Mac OS X (subject to all the conditions that GCC 3.3-compiled kexts followed). Regardless, you must make a few changes to your kext to get it to compile.

Kernel extensions cannot have statically initialized auto (function-local) variables that call C++ constructors. This is because he kernel does not provide locking routines around the initialization of auto variables. (Such locking routines could trigger nasty side effects in the kernel.) Although your code should compile fine, it will fail to load because the symbols for the missing locking code (___cxa_guard_abort, ___cxa_guard_acquire, and ___cxa_guard_release) are undefined. To correct the problem, you must move the local variables to the top level:

static A* globalArrayOfA = new A[10];

int A::foo(int i)

{

    static A* arrayOfA = new A[10];

    return arrayOfA[i].value();  // KEXT LOAD ERROR: __cxa_guard_abort undefined

    return globalArrayOfA[i].value();  // OK

}

Many kexts try to cast member function pointers to make them appear as if they are simply function pointers. This is done so that the member function can be registered as an interrupt handler. GCC 4.0 disallows such casts. Instead, you must use the OSMemberCastFunction macro to perform the cast correctly. This macro is available in Mac OS X v10.4 and should work identically with GCC 3.3 or GCC 4.0, and with the same behavior as the original code when compiled with GCC 3.3.

int A::bar(int i)

{

    handler = (IOInterruptAction) &A::interruptHandler; // ERROR: converting from `int (A::*)(int)' to `int (*)(int)' in a kext.  Use OSMemberFunctionCast() instead.

    return (*handler)(5);

}

int B::bar(int i)

{

    handler = OSMemberFunctionCast(IOInterruptAction, this, &B::interruptHandler); // OK

    return (*handler)(5);

}

Warnings About Incorrect Code

The following sections explain some of the other types of warnings and errors you may encounter during compilation.

class C

{

    virtual int PrepareCFBundle() = NULL; // ERROR: invalid initializer for virtual method

    virtual int PrepareCFBundle() = 0; // OK

};

foo: }

foo: ; }

bufferSizeNeeded = offsetof(ATSUGlyphInfoArray, glyphs[numGlyphs]); // ERROR:

// Instead, do this.

bufferSizeNeeded = (char*)&(((ATSUGlyphInfoArray*)0)->glyphs[numGlyphs]) - (char*)0;

// The following macro won't work in GCC 4.0 because the type of

// value is considered to be a bitfield that can't be used in typeof.

// In GCC 3.3, it would have been treated as an int.

#define STRUCT_VALUE(x) ((x->isSet ? x->value : (typeof(x->value))0))

struct a

{

    int isSet: 1;

    int value:15;

};

int foo(struct a *instance)

{

    return STRUCT_VALUE(instance);

}

void myFunc()

{

    int i = 1;

    myOtherFunc(i, i++);    // Warning! Operation on 'i' may be undefined.

}

void myFunc()

{

    int i = 1;

    myOtherFunc(i, i);

    i++;

}

Thread Safety and Static Local Variable Initialization

To maximize thread safety, GCC 4.0 automatically adds locks around any code that initializes local static variables in C++. If you do not need this protection and want to reduce your code size slightly, you can disable the locking behavior by passing the -fno-threadsafe-statics option to the compiler.

Examine System Library Usage

The first step to resolving link issues is to examine your system library usage. In Mac OS X v10.3.9 and later, both libgcc (the C support library) and libstdc++ (the Standard C++ library) are implemented as dynamic libraries. These libraries are linked into your program automatically by the GCC 4.0 compiler (rather than ld). If you encounter multiply defined symbols from these libraries, you may be including the static versions of these libraries on your link line.

Check to see if your project links against the libgcc.a, libstdc++.a, or libcc_dynamic.a static libraries. If it does, you should remove those libraries from your link commands.

If you compile your C++ application outside of Xcode, initiate the link phase using g++, and not ld, to ensure the inclusion of the correct libraries.

Check Any Linked C++ Libraries

Once you have resolved any link issues with the system libraries, look at the other libraries on your link line. If you link to any libraries that contain a C++ interface and were created using GCC 3.3, you must remove them from your link line.

The C++ application binary interface (ABI) changed between GCC 3.3 and GCC 4.0. Any application or library linking against a library that exports C++ functions must be built with the same compiler. Such problems are usually obvious when you check the list of undefined symbols. If the linker complains that any symbols starting with _ZTI are undefined, you are probably compiling a program using a mix of GCC 3.3 and GCC 4.0 binaries.

In your own libraries, you can use the -Wabi flag to tell the GCC compiler to issue warnings when it generates code that is not compatible with the vendor-neutral C++ ABI. For more information about this flag, see the gcc man page.

Check Your C++ Library Exports

If you are building a C++ library and limit the symbols exported from your library, you should verify that your library exports the symbols you expect.

By default, GCC 4.0 marks most symbols as private to prevent them from being exported. This is a change from the GCC 3.3 behavior but has significant advantages, particularly for C++ developers. Setting the default symbol visibility to private reduces the size of the exported symbol tables. If your code makes extensive use of templates, this size reduction could be huge.

If you don't want the space improvements triggered by making most symbols private, you can tell GCC 4.0 to export most symbols in the GCC 3.3 manner. To do so from Xcode, turn off the "symbols private by default" setting for your target. To do so from the GCC command line option, specify the -fvisibility=default option on the command line.

For more information regarding C++ symbol visibility and runtime behavior, see C++ Runtime Environment Programming Guide.

Known Code Changes

The code optimizer in GCC 4.0 is very different from the ones in previous versions of GCC. If you discover incorrect behavior in your recompiled code, or if you encounter crashes, check for the following known issues:

• The optimizer in GCC 4.0 may change the order of computations for some mathematical operations (such as addition or multiplication).

• Casting a member-function pointer to a regular function pointer now works differently in GCC 4.0. Prior to GCC 4.0, such casts were resolved at runtime, which meant that the address of the function was based on the actual type of the object at the call site. For example, suppose you request the address of A::MyFunction from another method of A. If the actual type of the object at runtime is B (a subclass of A) and B defines its own version of MyFunction, you would actually get the address of B::MyFunction. In GCC 4.0, the address of these functions is now calculated at compile time. So now, if you ask for &A::MyFunction, you will always get the address of A::MyFunction.

For arithmetic operations, the C and C++ standards state that subexpression evaluation order is undefined; the compiler is free to evaluate the arguments in addition or multiplication expressions in any order it wants. There are exceptions to this rule, however. These exceptions include the following types of subexpressions, which are all evaluated from left to right:

• && operators

• || operators

• ?: operators

• , (comma) operators

If one of these subexpressions has side effects, you might notice different behavior in GCC 4.0, depending on how the optimizer has reordered the code. You can use the -Wsequence-point flag to find any code that may have undefined semantics.

Optimization Changes for Inline Functions

The inlining algorithms in GCC 4.0 are much better at deciding when to inline functions rather than call them. The side effects of this optimization, however, are larger binaries and faster code. In many cases, you should not see any significant differences unless you have been overriding the default parameters that control inlining in your project. If you currently use the inlining parameters -finline-limit=xxxx or --param, do not continue to use the currently assigned values for those parameters. Instead, profile your code again and see what parameters offer the best balance between code size and speed for your application.

Internal testing has shown that projects using the -finline-limit option under GCC 3.3 would see code size increases of up to 30% and compile time increases of up to 50% under GCC 4.0. For -finline-limit, the default value is usually 600. If you use the -Os flag to optimize for size, the default value drops to 10. If you manually assign a limit of 200 or more to the -finline-limit flag, you are liable to see larger binaries than you did using the same settings under GCC 3.3.

Forcibly Inlining Functions

If you want to force a routine to be inlined all the time, do not assume the compiler will do it for you. Tell the compiler you explicitly want the routine inlined by adding the always_inline attribute to it, as shown in the following example:

void MyInlineFunction(int c) __attribute__((always_inline))

Data Type Size Differences

For many basic data types, such as bool and int compilers are at liberty to define the size of those types as they see fit. If you have code that expects these types to be a specific size, your code may not behave as expected. The transition to Macs that use Intel processors and differences between 32-bit and 64-bit binaries make it very important that you do not assume the size of some data types.

For string data, you should also not make assumptions about the size of character data types such as wchar_t. On Mac OS X, this type is typically 2 bytes wide, but on most UNIX operating systems it is 4 bytes. If you really need two-byte character data, manipulate your strings using CFString objects and examine the resulting characters using the UniChar data type. If your program retrieves strings from external sources, you can convert them using the CFStringCreateFromExternalRepresentation function. (You can also use the iconv function on UNIX; see man 3 iconv for details.)

Objective-C and Selectors

When a message is sent to a receiver of type id, the compiler looks at all matching selectors and warns about inconsistencies in argument types. GCC 4.0 is better at this than GCC 3.3 was and may reveal inconsistencies that were previously hidden. Although currently disabled, you can enable these warnings using the -Wstrict-selector-match flag. In the future, the compiler will warn about these inconsistencies by default.

Here are 3 examples of this warning that occurred in the Sketch example application:

 NSNotification.h:40: warning: using `-(void)postNotificationName:(NSString  *)aName object:(id)anObject' NSDistributedNotificationCenter.h:59:  warning: also  found `-(void)postNotificationName:(NSString *)aName object:(NSString  *)anObject' 

 NSNotification.h:37: warning: using `-(void)addObserver:(id)observer  selector:(SEL)aSelector name:(NSString *)aName object:(id)anObject'  NSDistributedNotificationCenter.h:57: warning: also found  `-(void)addObserver:(id)observer selector:(SEL)aSelector name:(NSString  *)aName  object:(NSString *)anObject' 

NSView.h:115: warning: using `-(NSWindow *)window'

NSAlert.h:125: warning: also found `-(id)window'

To fix these, use explicit casts or change the method definitions so that calls and definitions match.

Objective-C Instance Variables

In Objective C, instance variables are labeled as @protected by default. GCC 4.0 now explicitly warns about this, and future versions of the compiler will treat this as an error. To correct this problem, you should explicitly identify the scope of instance variables in your Objective-C interfaces.

Things You Should Not Do

There are cases where combinations of particularly ugly or strange casts can generate the following warning:

Pictures.c: In function 'StdOpcode':

Pictures.c:1132: warning: function called through a non-compatible type

Pictures.c:1132: note: if this code is reached, the program will abort

In these cases, the compiler really does insert an abort instruction rather than try to generate what it thinks is an incorrect function call. If you see this warning, you should absolutely fix it by removing or changing the cast so that the compiler can call the correct function.